I am playing with DxScene and VxScene:
http://www.ksdev.com/dxscene/index.html
It looks very nice and powerful: 3d accelerated vector graphics, cross plaform, nice effects, many 2d GUI controls (vector based), good scaling, transparency, rotating (x, y, z), 3d models, etc. Even with many effects, the CPU stays very low (0%)!
http://www.ksdev.com/dxscene/snapshot/screen0.jpeg
But can it be seen as a good WPF alternative for Delphi?
And does anyone use it instead of normal Delphi VCL?
Yes, I am using it now in a new project and intend to use it for all future projects.
It's indeed extremely powerful and versatile. It does consume SVG and even XAML, among many other formats, so you could consider it as a Win32 API WPF alternative. Believe me, I've been looking for one for ages, and this is it for me.
Current drawback: lack of documentation. You have to learn it all from the examples and by asking questions in their forum. Not ideal, but it can only get better!
All it needs is more users, and it'll grow into something wonderful.
I'm not sure, but it looks like it's the GUI base for FlStudio
It looks very promising, the effects are very good, in the past years I have seen it's being enhanced constantly. I have check it the second time today (only the compiled demo), it seems that many new controls are added, I like the "expander" expandable panel.
It's very promising, I'm consider using it in the future, I'm not sure if the new version has fix or not, but when the first time I checked the trial version, it lacks of documentation...
Very good effect and promising though!
You might find this article interesting, it explains how to use the DirectWrite and Direct2D features in Delphi 2010, it seems to be rather simple, and is well explained here: Delphi 2010 DirectWrite "Hello World" Example [1].
Screenshot from the article showing the result.
[1] http://blogs.embarcadero.com/pawelglowacki/2009/12/14/38872
Related
I'm trying to use FluidMoveBehaviour from the Dynamic Layout and Styles presentation at MIX 2010 in combination with MVVM (Caliburn.Micro).
The Master/Detail behavior is what I'm after. It isn't working and I would like to find out what's happening behind the curtains to see why Silverlight is not picking it up.
How can I debug the FluidMoveBehaviour?
Because the FluidMoveBehavior is so encapsulated and because the source code is not available, the only recourse when it is not working as expected is trial and error. Even worse, the feature is conceptually very opaque and the implications of what will happen if you change the settings are not at all clear initially.
Your best hope of getting the master/detail scenario to work (the most complicated one) is to create a very small example, get it working, and gradually reintroduce your code until it is fully integrated.
There are other working examples besides the MIX10 demo. I recommend reading and re-reading Mike Taulty's explanation until the feature is less opaque:
Blend Bits 14: Fluid Movement
Notice how he approaches the problem gradually and with little test programs. That is how to avoid wasting time trying to use a "black box" feature.
Anyway, the promise of "effortless interactivity" might ring rather hollow right about now. It is perhaps a lesson for other behavior developers: how will the clients debug it when it isn't working? The answer: give them the tools, like configurable logging. When it's not working, the silence is unbearable.
I am using delphi as my primary development tool.
and recently I found these 2 libraries in KSDEV.com
and i found they are similar to WPF . So i just downloaded them and stated to playing with them until the time to end comes ( i have not checked its license policies yet). I am not a good WPF knowledge person but i found was WPF hard to develop.
But my doubt is , are these 2 libraries can replace WPF in delphi . what are the drawbacks Dxscene and VGscene have or what are the drawbacks WPF have ,
There are only a little articles about them in internet (google gave me millions of results but most of them repeated 2 articles which was published in KSDEV)
VGScene and DXScene can be compaired to WPF for the rendering result.
I think VG/DXScene are less resource consuming, and what I like against WPF, is that they are not XML-based.
You use regular Delphi components to define your UI.
But the learning curve and the documentation is still a bit lacking for VX/DXScene.
I found out to be a bit difficult to create forms with DXScene. VXScene is perhaps a bit easier to create your UI with the mouse.
I think the full power of these libraries will be obtained using code-generated UI.
I don't like the XML root of WPF. It's verbose, and difficult to work with, with real application with a lot of forms. For some projects, the external WPF designer could be necessary.
But don't ask Microsoft why they don't publish WPF-based applications... and they still use unmanaged code...
VgScene and DxScene are really cool libraries! You can make fast and nice looking GUI's with all kind of effects. It also has a grid component now!
But when I tried using them, I encountered some "drawbacks": there is little documentation how to make and what to use for a complex GUI (there are some nice demo's for simple GUI's though). So it has a relative high learning curve (when you only have VCL knowlegde because it is very different).
But besides these things, I think it is worth trying (only if you know how to do it and/or spend some time learning). It has good platform support (via FPC and OpenGL) so you can run it also on MacOs, Linux and iPhone/iPad!
Since they do not depend on WPF, they can be used for cross platform development in Lazarus/CodeTyphon. That is the main advantage for me. Drawback is documentation.
From .NET Rocks! Show #488:
Richard Campbell: "In the GDI world we
got a document from Microsoft that
said you will build your apps in
battleship gray and here's now they
should look: File goes here and Help
goes here, and we all got that as
developers. There's no book like that
for WPF. There was this idea I've got
to find the guy in a black turtleneck
and here is his piece of software and
you guys go play nice now."
I think Microsoft now wants every Windows application to look like the ugly, difficult-to-use, hardware-bundled crapware we all hate!
Is there no such best-practices document?
There is a Windows User Experience Interaction Guidelines document that Microsoft makes available. It might be along the lines of what you are looking for, but it isn't specifically a WPF or Silverlight best practices guide.
Nobody has paid much attention to MS ui guidelines in a very, very long time (including MS). It is a big part of the reason why every app on windows looks and behaves different from every other app.
Depends on the guidance you're looking for. The primary reason everything was battleship grey in Winforms was less because the Microsoft guide said it should be (it didn't) and more because that was the default and it was a pain to write it differently. Even now, I would imagine that the bulk of the LOB apps written with Silverlight or WPF will use default colors and styles for exactly the same reasons.
But a lot of the other UI guidelines can still apply. If you want something the looks and feels familiar, there's no reason that you can't make a standard menu bar with File, Edit, View, Help, etc. You can still use the same hotkeys, same commands, same layout for buttons and controls.
Keep in mind though that these guidelines were written with assumptions about software and computers in general that are no longer true. The dominant paradigm has changed and people are far more used to websites with different UI layouts and richer visuals. As a result, visual style is a lot more diverse and people are less likely to be confused by some non-standard layouts and controls. Which doesn't mean that anything goes, just that we should feel less contrained to keeping things in the exact same order and position, lest our customers freak out because they can't find the save button.
In short, the style guide was there because there wasn't enough for a real designer to do but still enough that we developers could make things ugly. Now it's even easier to make really ugly stuff, but there's a lot that a real designer can do to make it nice. So hire one. It's worth it.
To be a 'silverlight' developer, is it basically asking for both programming and graphic skills?
Or is it just a matter of implementing the graphics into the silverlight project?
i.e. can you be a silverlight guru and yet not know heads from tails when it comes to graphic design?
To be a silverlight developer, you really only need to know a .NET language, event driven programming, and how to use markup for XAML. It's pretty simple really; the XAML describes UI elements (which can all be handled by the designer) which can then be used in code as a .NET object is created for each UI element.
Knowing graphic design is just a bonus.
If it's anything like Flash (and, from what I understand, the "finished products" can have similar capabilities), you don't necessarily need to be a designer. I'm part-flash developer and I don't have the first idea about anything related to graphic design :)
When I do flash programming, 99% of the work I do is in Actionscript. We have a couple of asset prep guys here who extract the visual elements and add them to a library, which us developers then use in the flash app.
Like I say, this is assuming there are some similarities between Flash and Silverlight (which, for all I know, may not exist). Good luck!
thats the power of xaml, both coder and designer can work in one language ;)
I've done a couple of WPF and Silverlight projects and I have terrible graphic design skills. You can certainly do Silverlight without having that type of skillset.
However, even though you can do some attractive work in those projects without having graphics skills it still very useful to have access to somebody that does have the skills.
For example, adding small animations to glassy-looking buttons can be entirely done by a programmer. But adding attractive backgrounds to form headers (other than gradients) is still better handled by a graphics guy. (In my opinion, of course)
It is not strictly necessary to be a good graphic designer, knowing how to develop .NET applications and XAML is sufficient. However, it's like drawing, all you have to do is to hold a pencil and move your hand, but if you have a good sense for art, the result will be better. Since in Silverlight your potential targets are Internet users and they're used rich user interfacese (maybe Flash based), if you know how to organize your elements, which are the best colors and things like that, your work will be easier.
We are implementing an application that needs dockable windows, similar to Visual Studio 2005/2008, but with multiple "docking sites", unlike VS's single one. Does anyone have a recommendation on a good library for this - either OSS or commercial? I am aware that Infragistics has one, as well as Divelement's SandDock and WPF-Dock from DevComponents, as well as ActiPro's Docking & MDI product. There is also one on CodeProject. Has anyone used any of these libraries? Was the experience good or bad? If you have experience with one of them, does it support multiple "docking sites"?
The one from Codeproject is the AvalonDock - we use it for more then half a year now, but we're far from release yet so we have the flexibility. Before ending up with AvalonDock we tried Infragistix, ActiPro, SandDock and may be some others.
Even though AvalonDock is not 100% bug free (well what is?) there are no major ones, it is very stable, fast and has all the functionality. It does support multiple docking sites.
Its an open source project and is in active development, so bugs are beeing found and fixed. Good experience so far.
I've been using the ActiPro library for several months and it's done me well. It does support multiple docking sites. The support is outstanding and you get some other controls (date picker, etc) that are missing from WPF. To me, for $150 it's money well spent. It worked out of the box, no fuss.
We used to use Divelements for WinForm controls but we think Actipro has better support, so we switched for WPF.
Just my two cents.
Don't forget AvalonDock on GitHub (part of WPF Toolkit). I've seen it mentioned in other places.
Initially I was going to use the ActiPro library (mostly because I am already using their ribbon), but I might give AvalonDock a chance since it is open source.
Anybody have any feedback/comments on AvalonDock?
I use DotNetBar, because it has ribbon/dock and more controls, and it's inexpensive. It's great.
http://www.devcomponents.com/dotnetbar-wpf/
SandDock is alright. We used it for a POC phase of a project. I found some pretty bad bugs in their layout saving mechanism. It generated XML, but then couldn't load this XML back; it threw an exception! I actually read through all the generated XML and had to write code to modify the XML slightly after each time it was generated. It did not seem like it was a well thought out design; I was hoping for common WPF base types like
Infragistics is a bit better but buggy. In fact, if you try running it on a machine that only has .Net 3.0 and no .Net 3.5, it doesn't work correctly. Have an outstanding dev issue with Infragistics and I don't know if they've made any progress on a fix for this. I've also had it crash a few times when floating a window and dragging it around (suspect this has to do with the .Net 3.0/3.5 issue above). I've found styling this control to be pretty un-intuitive.
I tried all the libraries listed here and they're all buggy to some extent. Although they are pricy I would recommend Telerik and Infragistics. Nevron merits a mention because their library is the best I've seen but it's for WinForms.
1 year later ...
AvalonDock is now stable and robust.
There's also an "AvalonDock wrapper" that simplifies working with it without reducing its possibilities.
See http://sofawpf.codeplex.com/
Here is another one:
http://www.essentialobjects.com/Products/EOWpf/DockView.aspx
This one has a number of built-in skins that you can switch dynamically. It also has many individual controls (such as a "Splitter" control) that you can use independently.