Building a perfect wpf developer workstation
-
John Cardinal wrote:
To be honest the "luddite" replies I'm seeing and yours are symptomatic of not really taking the time to understand what the benefits are and how it all works, once you get into that you will see it intuitively.
I fully understand that. However, the question for me is: Should I really look into it? (I guess this sounds heathenish to you ;)) The company I work for is leading (and often enough bleeding) edge for what it does, but the market does not throw at us the resources to jump on a new UI paradigm every seven years. My job is to provide engineers with the environment they can program in, and they have absolutely no patience for "that Windows Shit". They have a completely different opinion of what a UI may cost. My job can get very frustrating between them and the MSDN headlines of today, so to not get exhausted I have to leave one thing behind. Microsoft always pushed out new technologies, but recently it seems to me they get outdated before they mature. WPF is cool, but will it be still cool in five years, or can I sit it out and skip to the next best thing? No problem for cute small apps, but I happen to work on one that puts a lot functionality into one place.
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
Reading that just convinces me more that it's time to retire.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Me too.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
peterchen wrote:
The list is scary for one reason: How many developers does it take to write the UI for an mid-size windows application? One? A half? zero point one?
I gurantee you it will take one because I've done it with MFC then winforms and from what I'm learning about wpf I'll be able to do it much more quickly with wpf. While you *could* have turning pages and rotating whatsits the real power and improvement I see is moving every last bit of the UI stuff *out* of the code and being able to do layout in a much cleaner and simpler way that results in better layouts that I currently have to write a *lot* of c# to get with winforms. To be honest the "luddite" replies I'm seeing and yours are symptomatic of not really taking the time to understand what the benefits are and how it all works, once you get into that you will see it intuitively. To be fair when Orcas is out you will again be writing wpf apps on a Vista station "out of the box". WPF has crossed the "bleeding edge" territory and is now firmly in the leading edge, something that I like to stay on top of in particular because we have a small shop and can't turn around a new app as quickly as some bigger shops. I really benefited from being on top of winforms in the early days and got a release out just on the sweet spot of .net adoption. You can't afford to be a "luddite" in this business unless you're content to be relegated to maintenance programming. People are understandably upset when they have to learn something new in any industry, but in the programming industry it's just a way of life. And I've learned and worked with 6502 assembly, 8080 assembly, cobol, C, MFC / C++ etc etc. It can suck if you take it with the wrong attitude but if you embrace it you can make a lot of money and get to play with cool new things and make a lot of customers happy.
John Cardinal wrote:
It can suck if you take it with the wrong attitude but if you embrace it you can make a lot of money and get to play with cool new things and make a lot of customers happy.
Very true!
:josh: My WPF Blog[^]
-
John Cardinal wrote:
ability to build an app once that can be run as a windows client app or through a web browser without changing any code. In theory it could put an end to that debate.
That does sound interesting, but I don't see how it could escape the trap that cross platform libraries have always encountered: the lowest common denominator. Consequently, it sounds like this scenario would essentially amount to writing a web app (the lowest common denominator) and then spitting out an extremely limited client app. Yuck. On the other hand, if I could write an extremely cool client app using all the horsepower available to me (which is what I miss about web development) and then click a "by the way, generate the best web stuff you're capable of based on this" button and get the web app for free, well, that might be worthwhile. Got any idea which of these two scenarios approaches reality?
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
Christopher Duncan wrote:
Got any idea which of these two scenarios approaches reality?
Both are possible. When creating a WPF app which will be compiled down to both an EXE and, in a separate compilation, an XBAP, there are certain restrictions which must be kept in mind during the design and development periods. If the app is going to be installed via a plain vanilla MSI, then the world is your oyster. There are no security concerns to keep in mind. Access the registry and delete a file, go crazy. If you're deploying via ClickOnce then you must keep in mind all of the loving goodness which the .NET Framework imposes on semi-trusted apps. This is no different than using ClickOnce with WinForms. Lastly, a WPF app deployed as an XBAP (a browser app) lives in a much more locked down world than its fancy free brethren. As of WPF v1, XBAPs are given very few privledges. For example, you can't even open another window (no popups). I'm not going to list all of the restrictions here because who the heck would bother reading it, but I can say that MSFT has already caught mucho fuego from the WPFers out there about it. They say that they're going to figure out ways to relax the restrictions placed on XBAPs by default (yay!). I hope that helps to answer your question.
:josh: My WPF Blog[^]
-
Reading that just convinces me more that it's time to retire.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Christopher Duncan wrote:
Got any idea which of these two scenarios approaches reality?
Both are possible. When creating a WPF app which will be compiled down to both an EXE and, in a separate compilation, an XBAP, there are certain restrictions which must be kept in mind during the design and development periods. If the app is going to be installed via a plain vanilla MSI, then the world is your oyster. There are no security concerns to keep in mind. Access the registry and delete a file, go crazy. If you're deploying via ClickOnce then you must keep in mind all of the loving goodness which the .NET Framework imposes on semi-trusted apps. This is no different than using ClickOnce with WinForms. Lastly, a WPF app deployed as an XBAP (a browser app) lives in a much more locked down world than its fancy free brethren. As of WPF v1, XBAPs are given very few privledges. For example, you can't even open another window (no popups). I'm not going to list all of the restrictions here because who the heck would bother reading it, but I can say that MSFT has already caught mucho fuego from the WPFers out there about it. They say that they're going to figure out ways to relax the restrictions placed on XBAPs by default (yay!). I hope that helps to answer your question.
:josh: My WPF Blog[^]
Great stuff, man - thanks for taking the time to explain!
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
-
John Cardinal wrote:
Zero items on that list are required to write wpf applications on vista, it's all just tools and components to make life easier.
To exaggerate: "You don't need Visual Studio for that, you can write this in Assembler!" (and some people really did) I learnt, and did, MFC with VC++ 5 out of the box and MSDN. The list is scary for one reason: How many developers does it take to write the UI for an mid-size windows application? One? A half? zero point one? Or, to put it another way: In one year, how many developers will be available that are able to provide a commercially viable UI (i.e. doesn't fall over when it encounters a Spanish Windows or a non-standard Installation directory), and still have the skills and time to do something else? And how long will their skills be Industry Standard? Don't get me wrong: WPF looks cool. But turning book pages and slightly rotated note sheets won't get me one customer more. Still, people expect a "standard windows application", and if WPF raises the bar to high, we might be forced to be luddites for the sake of a product.
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us!peterchen wrote:
To exaggerate: "You don't need Visual Studio for that, you can write this in Assembler!" (and some people really did)
I've seen the win32 for asm programmers library before. :omg::wtf::omg::wtf::omg::wtf::omg::wtf::omg: :wtf::omg::wtf::omg::wtf::omg::wtf::omg::wtf: :omg::wtf::omg::wtf::omg::wtf::omg::wtf::omg: :wtf::omg::wtf::omg::wtf::omg::wtf::omg::wtf: :omg::wtf::omg::wtf::omg::wtf::omg::wtf::omg: :wtf::omg::wtf::omg::wtf::omg::wtf::omg::wtf: :omg::wtf::omg::wtf::omg::wtf::omg::wtf::omg: :wtf::omg::wtf::omg::wtf::omg::wtf::omg::wtf: :omg::wtf::omg::wtf::omg::wtf::omg::wtf::omg:
-- Rules of thumb should not be taken for the whole hand.
-
John Cardinal wrote:
It can suck if you take it with the wrong attitude but if you embrace it you can make a lot of money and get to play with cool new things and make a lot of customers happy.
Very true!
:josh: My WPF Blog[^]
-
John Cardinal wrote:
I needed you to back me up here yesterday
Battling luddites is futile. ;)
:josh: My WPF Blog[^]
-
Daniel Grunwald wrote:
But then again it's possible to write something like a WPF designer as a pure WPF application - no nasty P/Invokes, WndProc overrides or overlay windows for the drag handles that a Windows Forms designer would need.
That was one of the requirements I made of the framework that I work on (the VCF). The form designer that I built is built entirely using the VCF, no extra WndProc's or customizations beyond the framework itself. The proof is in the pudding: http://vcfbuilder.org/?q=node/116[^] http://vcfbuilder.org/?q=node/105[^] Plus the VCF uses a text based form file whoe format is extremely simple to read and parse, for example:
object Form1 : Window, 'ED88C0A1-26AB-11d4-B539-00C04F0196DA'
left = 200.1
top = 200.1
width = 500
height = 500
caption = 'My Form'object label1 : VCF::Label, 'ED88C09F-26AB-11d4-B539-00C04F0196DA'
anchor = [AnchorLeft,AnchorRight]
caption = 'This is a label!'
left = 20.00000
top = 20.00000
width = 100.00000
height = 35
color.blue = 0.50000
color.green = 1.00000
color.red = 0.00000
textAlignment = taTextLeft
verticalAlignment = tvaTextCenter
end
object button1 : VCF::CommandButton, '8B2CDC30-3CAD-11d4-B553-00C04F0196DA'
caption = 'Hola!'
left = 30
top = 367
height = 35
width = 300
end
endThe above will create a form, with a green label and a button.
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Techno Silliness
The similarity between your code example and a Delphi/C++Builder DFM file are amazing :) Seriously though, with stuff like this it seems that between the designer and WPF (is that the right acronym, I can never remember...) .NET and VCF are making some real strides. One thing that Borland and VCL (by the way, does VCF stand for "Visual Component Framework"?) never managed was a way of making it easy to separate the UI/ Event handlers from the business logic. It's just too easy to go to the generated event handler function stub and start coding. Do you have a plan in mind for that?
-
The similarity between your code example and a Delphi/C++Builder DFM file are amazing :) Seriously though, with stuff like this it seems that between the designer and WPF (is that the right acronym, I can never remember...) .NET and VCF are making some real strides. One thing that Borland and VCL (by the way, does VCF stand for "Visual Component Framework"?) never managed was a way of making it easy to separate the UI/ Event handlers from the business logic. It's just too easy to go to the generated event handler function stub and start coding. Do you have a plan in mind for that?
Yeah, well I was a *big* Delphi fan before I gave it up (I'm still sad about that). So when I started the VCF I purposely modeled a great deal of it on Delphi. In the VCF there exists a more formal Model/View design than there was in Delphi (at least by version 3/4). Also, all the delegates in the VCF are "multi-cast", so many external event handlers can be hooked up. I think the problem Borland never got right was how to hook up an event handler in some external object to some delegate on a form, or other UI element. This is easy to do in code with the VCF, though the designer doesn't yet support this.
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Techno Silliness