Longhorn, what does everyone think?

[JDeats]

Just spent some time browsing around here:
http://msdn.microsoft.com/Longhorn/

I can see the benefits from WinFS (as long as we tag all in-coming
data this should be nice, tagging everything could be a tedious
process though) but I haven't been able to pick up the practical
advantages of XAML. From my assessment, XAML will provide separation
of UI logic from business rules/procedures for applications. It seems
like an HTML of sorts for desktop application UI. But where are the
big advantages of designing desktop applications this way? It may
provide a nifty way to create UI-"skins" to provide a custom
experience for different users, but that can do as much harm as good,
it's not revolutionary.

I can think of some disadvantages to this approach, namely all the UI
logic has to processed at run-time (interpreted) and a generic
container application has to exist to marshal between the presentation
and the procedure code. Even if this marshall process is part of the
core OS, it still seems like needless overhead without any
clear-advantages.

Also the Longhorn UI guidelines are nothing to wow over, there's a new
side-docking bar that we can use to provide small bits of information
at all times, it's going to get cluttered quickly.

I don't know about most of you, but with all the processing power or
modern PCs I was hoping for something more radical (how about a 3D
User Interface for the OS), am I alone here?

[Daniel Pratt]

Hi JDeats,

"JDeats" <je****@pdq.net > wrote in message
news:b0******** *************** ***@posting.goo gle.com...

Just spent some time browsing around here:
http://msdn.microsoft.com/Longhorn/

I can see the benefits from WinFS (as long as we tag all in-coming
data this should be nice, tagging everything could be a tedious
process though) but I haven't been able to pick up the practical
advantages of XAML. From my assessment, XAML will provide separation
of UI logic from business rules/procedures for applications. It seems
like an HTML of sorts for desktop application UI. But where are the
big advantages of designing desktop applications this way? It may
provide a nifty way to create UI-"skins" to provide a custom
experience for different users, but that can do as much harm as good,
it's not revolutionary.

I can think of some disadvantages to this approach, namely all the UI
logic has to processed at run-time (interpreted) and a generic
container application has to exist to marshal between the presentation
and the procedure code. Even if this marshall process is part of the
core OS, it still seems like needless overhead without any
clear-advantages.
I have for a long time now wished to have asp.net-ish features in my
windows app (flow layout, nested elements, cascading stylesheets, UI/logic
seperation, etc.). Until now it hasn't been worth the trade-offs for the
kind of applications I develop. It sounds to me like XAML brings what is
good about ASP.NET development to windows applications without the
trade-offs and that I'm pretty excited about.

I would not assume that XAML applications will be strictly interpreted.
ASP.NET doesn't run interpreted, after all, and XAML applications are able
to be converted into strictly windows apps. Between Windows itself and the
managed runtime, I would doubt that the container process (assuming there is
one) would add any significant overhead to the application.
Also the Longhorn UI guidelines are nothing to wow over, there's a new
side-docking bar that we can use to provide small bits of information
at all times, it's going to get cluttered quickly.
Looking at my icon tray this seems quite possible, yes.
I don't know about most of you, but with all the processing power or
modern PCs I was hoping for something more radical (how about a 3D
User Interface for the OS), am I alone here?

3-D seems like the inevitable direction for interfaces of the future,
but coming up with something that's more than just a gimmick seems like a
sizeable challenge, especially if you expect to make a smooth transition
from the 2-D interface world.

Regards,
Dan

[Alvin Bruney]

i'm interested to see if it will catch on, the resistance to change, the
separation into longhorn camps and longhorn biggots. interesting stuff. time
will tell.

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"JDeats" <je****@pdq.net > wrote in message
news:b0******** *************** ***@posting.goo gle.com...

Just spent some time browsing around here:
http://msdn.microsoft.com/Longhorn/

I can see the benefits from WinFS (as long as we tag all in-coming
data this should be nice, tagging everything could be a tedious
process though) but I haven't been able to pick up the practical
advantages of XAML. From my assessment, XAML will provide separation
of UI logic from business rules/procedures for applications. It seems
like an HTML of sorts for desktop application UI. But where are the
big advantages of designing desktop applications this way? It may
provide a nifty way to create UI-"skins" to provide a custom
experience for different users, but that can do as much harm as good,
it's not revolutionary.

I can think of some disadvantages to this approach, namely all the UI
logic has to processed at run-time (interpreted) and a generic
container application has to exist to marshal between the presentation
and the procedure code. Even if this marshall process is part of the
core OS, it still seems like needless overhead without any
clear-advantages.

Also the Longhorn UI guidelines are nothing to wow over, there's a new
side-docking bar that we can use to provide small bits of information
at all times, it's going to get cluttered quickly.

I don't know about most of you, but with all the processing power or
modern PCs I was hoping for something more radical (how about a 3D
User Interface for the OS), am I alone here?

[Jack Mayhoff [MSFT]]

Ya think Window will catch on? Do ya really?

--

Jack Mayhoff
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

"Alvin Bruney" <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote in
message news:es******** ******@TK2MSFTN GP10.phx.gbl...

i'm interested to see if it will catch on, the resistance to change, the
separation into longhorn camps and longhorn biggots. interesting stuff. time will tell.

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"JDeats" <je****@pdq.net > wrote in message
news:b0******** *************** ***@posting.goo gle.com...

Just spent some time browsing around here:
http://msdn.microsoft.com/Longhorn/

I can see the benefits from WinFS (as long as we tag all in-coming
data this should be nice, tagging everything could be a tedious
process though) but I haven't been able to pick up the practical
advantages of XAML. From my assessment, XAML will provide separation
of UI logic from business rules/procedures for applications. It seems
like an HTML of sorts for desktop application UI. But where are the
big advantages of designing desktop applications this way? It may
provide a nifty way to create UI-"skins" to provide a custom
experience for different users, but that can do as much harm as good,
it's not revolutionary.

I can think of some disadvantages to this approach, namely all the UI
logic has to processed at run-time (interpreted) and a generic
container application has to exist to marshal between the presentation
and the procedure code. Even if this marshall process is part of the
core OS, it still seems like needless overhead without any
clear-advantages.

Also the Longhorn UI guidelines are nothing to wow over, there's a new
side-docking bar that we can use to provide small bits of information
at all times, it's going to get cluttered quickly.

I don't know about most of you, but with all the processing power or
modern PCs I was hoping for something more radical (how about a 3D
User Interface for the OS), am I alone here?

[Daniel O'Connell]

"JDeats" <je****@pdq.net > wrote in message
news:b0******** *************** ***@posting.goo gle.com...

Just spent some time browsing around here:
http://msdn.microsoft.com/Longhorn/

I can see the benefits from WinFS (as long as we tag all in-coming
data this should be nice, tagging everything could be a tedious
process though) but I haven't been able to pick up the practical
advantages of XAML. From my assessment, XAML will provide separation
of UI logic from business rules/procedures for applications. It seems
like an HTML of sorts for desktop application UI. But where are the
big advantages of designing desktop applications this way? It may
provide a nifty way to create UI-"skins" to provide a custom
experience for different users, but that can do as much harm as good,
it's not revolutionary.

I can think of some disadvantages to this approach, namely all the UI
logic has to processed at run-time (interpreted) and a generic
container application has to exist to marshal between the presentation
and the procedure code. Even if this marshall process is part of the
core OS, it still seems like needless overhead without any
clear-advantages.
Basically, it provides a way to declaritivly design a UI. There is nothing
saying you HAVE to use xaml files to produce UI's, there are classes that
are directly usable, as well as winforms, it however provides alot of nice
features(such as using the WIndows Client Print Driver or things like Adobe
After Effects to produce UI's). xaml in most cases will be compiled into a
standard EXEs(however it can be loaded directly in a browser or a seperate
window, as I understand it.)
From what I read, xaml files are transformed into partial C# or VB.NET
classes, for example, and the associated code behind files provide other
parts of the partial classes, allowing you to seperate UI and code nicely in
some cases, but it still generates an executable class.
I don't consider XAML to be a revolution so much as an evolution of existing
concepts, evolved in such a way that it operates well within Windows. Total
revolution is really rather rare and I don't expect that anything major will
be totally revolutionary about longhorn(or any other major software,
revolution tends to come in little bits, in little projects until its
proven)

I think it might be nice...but until I get to play with it I won't know,
asp.net wasn't my favorite thing. However because XAML isn't required, I
think Avalon is far more important, XAML is just a different way to utilize
it.

Also the Longhorn UI guidelines are nothing to wow over, there's a new
side-docking bar that we can use to provide small bits of information
at all times, it's going to get cluttered quickly.

I don't know about most of you, but with all the processing power or
modern PCs I was hoping for something more radical (how about a 3D
User Interface for the OS), am I alone here?

I tend to shy away from 3d interfaces, I've seen very few that were really
usable. There is a level where you have to consider nice looks and
usability, and 3d interfaces often require to much work to get where your
going, not to mention they are difficult to manipulate with standard PC
HID's.

[Christoph Nahr]

On Wed, 29 Oct 2003 00:12:45 GMT, "Daniel O'Connell"
<[e-mail]> wrote:

From what I read, xaml files are transformed into partial C# or VB.NET
classes, for example, and the associated code behind files provide other
parts of the partial classes, allowing you to seperate UI and code nicely in
some cases, but it still generates an executable class.

As I understood the Petzold example, I don't think I'd put _any_ code
in XAML files. Sure, you can (in CDATA blocks), but that looks rather
clumsy and it's apparently unnecessary.

I think the most useful aspect about XAML is that you can use it as a
glorified resource script format that defines a UI's visual appearance
plus the event handlers to which all UI elements are mapped, but the
actual event code would be written in a normal separate C# file.
--
http://www.kynosarges.de

[Daniel O'Connell]

"Christoph Nahr" <ch************ @kynosarges.de> wrote in message
news:hs******** *************** *********@4ax.c om...

On Wed, 29 Oct 2003 00:12:45 GMT, "Daniel O'Connell"
<[e-mail]> wrote:

From what I read, xaml files are transformed into partial C# or VB.NET
classes, for example, and the associated code behind files provide other
parts of the partial classes, allowing you to seperate UI and code nicely insome cases, but it still generates an executable class.
As I understood the Petzold example, I don't think I'd put _any_ code
in XAML files. Sure, you can (in CDATA blocks), but that looks rather
clumsy and it's apparently unnecessary.

I think the most useful aspect about XAML is that you can use it as a
glorified resource script format that defines a UI's visual appearance
plus the event handlers to which all UI elements are mapped, but the
actual event code would be written in a normal separate C# file.

I probably wouldn't write inline code either(although they do make it clear
you could), however from what I read, I think the build would go something
like this:
Form.xaml -> partial class Form; containing code generated from Form.xaml,
including inline code
Form.xaml.cs -> partial class Form; containing code-beside\behind code in a
model similar to asp.net.
resulting in a form class object when compiled which is mostly what I
meant.(Unfortun atly I can't find the page I was reading that on...there is
really alot more up on that longhorn sdk site than it seems at first
glance).

However, for writing quick 'n dirty applications, note organizers or other
apps that may only consist of a UI and maybe 50 lines of code, inline coding
is potentially nice, no reason to launch VS, handle multiple files and a
build setup for that, when you can just write out a XAML file with some
quick C# in it.

Personally I'm not sure if I'd even be motivated to use XAML directly often,
I would most likely just use it inderictly via the designer or other tools.
If I'm designing a UI by hand, I like to do it in code...quirk from my
pre-designer days I guess, ;). It will remain to be seen what I think of it
once I get my hands on it, I'm not a fan of HTML and don't expect this to be
much better...but they may surprise me.

--
http://www.kynosarges.de

[JDeats]

> 3-D seems like the inevitable direction for interfaces of the future,

but coming up with something that's more than just a gimmick seems like a
sizeable challenge, especially if you expect to make a smooth transition
from the 2-D interface world.

Regards,
Dan

I expect whatever the next big leap is, it will start out as an
application that runs on top of the existing OS (just as Windows
started out as an application on top of DOS). With $6.5 million a year
spent on pure R&D, I'm just surprised Microsoft hasn't come up with
somethine more innovative. For people who don't play games on their
PC's I'd say about 80% of their video hardware's potential is left
completely untapped. How much power does it take to display a 2D
display at 1024x768 or even 1280x1024? in true color, you're average
16-bit video card with 16-MEG of RAM does the trick. But just about
every video card (even the motherboard basec chipsets) have 3D
capabilities, and most cards come with at least 32-MEG of RAM.

[Alvin Bruney]

Yay, more Z order :D Just what we need! Lets not simplify, lets complify!

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"JDeats" <je****@pdq.net > wrote in message
news:b0******** *************** **@posting.goog le.com...

3-D seems like the inevitable direction for interfaces of the future, but coming up with something that's more than just a gimmick seems like a sizeable challenge, especially if you expect to make a smooth transition
from the 2-D interface world.

Regards,
Dan

I expect whatever the next big leap is, it will start out as an
application that runs on top of the existing OS (just as Windows
started out as an application on top of DOS). With $6.5 million a year
spent on pure R&D, I'm just surprised Microsoft hasn't come up with
somethine more innovative. For people who don't play games on their
PC's I'd say about 80% of their video hardware's potential is left
completely untapped. How much power does it take to display a 2D
display at 1024x768 or even 1280x1024? in true color, you're average
16-bit video card with 16-MEG of RAM does the trick. But just about
every video card (even the motherboard basec chipsets) have 3D
capabilities, and most cards come with at least 32-MEG of RAM.

[Alvin Bruney]

Ignore this idiot. He is spoofing my email account

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"Alvin Bruney" <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote in
message news:uU******** ******@TK2MSFTN GP12.phx.gbl...

Yay, more Z order :D Just what we need! Lets not simplify, lets complify!

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"JDeats" <je****@pdq.net > wrote in message
news:b0******** *************** **@posting.goog le.com...

3-D seems like the inevitable direction for interfaces of the future, but coming up with something that's more than just a gimmick seems like

a

sizeable challenge, especially if you expect to make a smooth

transition from the 2-D interface world.

Regards,
Dan

I expect whatever the next big leap is, it will start out as an
application that runs on top of the existing OS (just as Windows
started out as an application on top of DOS). With $6.5 million a year
spent on pure R&D, I'm just surprised Microsoft hasn't come up with
somethine more innovative. For people who don't play games on their
PC's I'd say about 80% of their video hardware's potential is left
completely untapped. How much power does it take to display a 2D
display at 1024x768 or even 1280x1024? in true color, you're average
16-bit video card with 16-MEG of RAM does the trick. But just about
every video card (even the motherboard basec chipsets) have 3D
capabilities, and most cards come with at least 32-MEG of RAM.