[vwnc] Platform priorities

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[vwnc] Platform priorities

Steven Kelly
Re: [vwnc] wxWidgets? Re: Does Cincom give up the Desktop ?
Andre Schnoor wrote:
>Am 29.11.2009 um 10:43 schrieb Antony Blakey:
>> Another important choice is to start with OSX, not with Windows or 
>> GTK as your baseline.
>
> Indeed. MacOS X can safely be considered the
> most potent superset of all platforms.
That may or may not be true. Basing development too strongly on any one platform generally ends up being to the detriment of cross-platform behaviour. It's like writing a class hierarchy with the superclass being a particular concrete case.
 
I do worry occasionally about the increasing percentage of Mac OS X fans in these discussions, both within Cincom and without. Not that I have anything against the platform or those people - far from it - but I feel that personal preference shouldn't unduly influence the direction of the product. IMHO that direction should be determined by current and projected revenues from the different platforms, from Cincom's customers' customers. Obviously, Cincom have little chance to influence the platform choices of those people - even amazingly cool and accurate UI support for the wrong platform won't make them switch. However, the quality of VW's UI support on the platform they already use will have a significant influence on how many decide to buy.
 
IIRC I was told some years ago by Cincom that the total VW revenue was around 90% Windows-based. I'd imagine that figure has changed somewhat, but if it follows the percentage of users of platforms in general, maybe not by much.
 
In the last 5 years or so most new platform-specific VW development effort seems to have been expended on the Mac, and that actually makes sense to me. Linux isn't much of a market in terms of people actually paying for products. The (commercial) Windows world has stayed largely in XP, so business apps have been able to survive without a Vista L&F. (Which gives rise to another interesting question: what is the split of VWrevenue between apps for people at work, and apps for people at home?)
 
But with the coming of Windows 7, which looks likely to be a success for both home and business users, and the faltering of Snow Leopard, I imagine the market the majority of VW apps will be selling into will be Windows 7. It would be nice to see some action in VW development in that direction (ribbon, multitouch...), on top of the things that are de rigeur on all platforms (alpha, antialiasing...).
 
All the best,
Steve
 
 

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Dennis smith-4
It may be interesting to note that many people IN the computer business like the MAC,
but our experience with our clients is that in about 300 (+/-) I know of only about 3 who wanted
to use MAC's to access our VW-based applications -- the rest wanted Windows.

MAC may be great, I don't have the luxury as my job is to provide framework and applications for out
end users so I use Windows, and need to keep up with the releases too (even Vista).

Given the small number of MAC users, we don't provide a MAC version of our apps, we let them
use either Windows on a VM or some terminal-services-like entity -- so at least from our perspective
windows is pretty much 100% of our deployments.

I have no problem with CINCOM doing a better MAC, so long as things are not driven by MAC.

That said - up-to-date looks and feel is important on ALL fronts (MAC, Windows, ...) -- so I would like to
see some attention there.


Steven Kelly wrote:
Re: [vwnc] wxWidgets? Re: Does Cincom give up the Desktop ?
Andre Schnoor wrote:
>Am 29.11.2009 um 10:43 schrieb Antony Blakey:
>> Another important choice is to start with OSX, not with Windows or 
>> GTK as your baseline.
>
> Indeed. MacOS X can safely be considered the
> most potent superset of all platforms.
That may or may not be true. Basing development too strongly on any one platform generally ends up being to the detriment of cross-platform behaviour. It's like writing a class hierarchy with the superclass being a particular concrete case.
 
I do worry occasionally about the increasing percentage of Mac OS X fans in these discussions, both within Cincom and without. Not that I have anything against the platform or those people - far from it - but I feel that personal preference shouldn't unduly influence the direction of the product. IMHO that direction should be determined by current and projected revenues from the different platforms, from Cincom's customers' customers. Obviously, Cincom have little chance to influence the platform choices of those people - even amazingly cool and accurate UI support for the wrong platform won't make them switch. However, the quality of VW's UI support on the platform they already use will have a significant influence on how many decide to buy.
 
IIRC I was told some years ago by Cincom that the total VW revenue was around 90% Windows-based. I'd imagine that figure has changed somewhat, but if it follows the percentage of users of platforms in general, maybe not by much.
 
In the last 5 years or so most new platform-specific VW development effort seems to have been expended on the Mac, and that actually makes sense to me. Linux isn't much of a market in terms of people actually paying for products. The (commercial) Windows world has stayed largely in XP, so business apps have been able to survive without a Vista L&F. (Which gives rise to another interesting question: what is the split of VWrevenue between apps for people at work, and apps for people at home?)
 
But with the coming of Windows 7, which looks likely to be a success for both home and business users, and the faltering of Snow Leopard, I imagine the market the majority of VW apps will be selling into will be Windows 7. It would be nice to see some action in VW development in that direction (ribbon, multitouch...), on top of the things that are de rigeur on all platforms (alpha, antialiasing...).
 
All the best,
Steve
 
 

_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@...
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Michael Lucas-Smith-2
In terms of support of platforms, I don't think there's any particular
mac bias in engineering. A bunch of us use mac because it let's us run
mac, windows and linux all on one machine. Many of us might prefer the
mac environment, especially since it has BSD underneath it. I wouldn't,
however, say that cocoa widgets have a particular advantage over windows
widgets.

Michael

Dennis Smith wrote:

> It may be interesting to note that many people IN the computer
> business like the MAC,
> but our experience with our clients is that in about 300 (+/-) I know
> of only about 3 who wanted
> to use MAC's to access our VW-based applications -- the rest wanted
> Windows.
>
> MAC may be great, I don't have the luxury as my job is to provide
> framework and applications for out
> end users so I use Windows, and need to keep up with the releases too
> (even Vista).
>
> Given the small number of MAC users, we don't provide a MAC version of
> our apps, we let them
> use either Windows on a VM or some terminal-services-like entity -- so
> at least from our perspective
> windows is pretty much 100% of our deployments.
>
> I have no problem with CINCOM doing a better MAC, so long as things
> are not driven by MAC.
>
> That said - up-to-date looks and feel is important on ALL fronts (MAC,
> Windows, ...) -- so I would like to
> see some attention there.
>
>
> Steven Kelly wrote:
>> Andre Schnoor wrote:
>> >Am 29.11.2009 um 10:43 schrieb Antony Blakey:
>> >> Another important choice is to start with OSX, not with Windows or
>> >> GTK as your baseline.
>> >
>> > Indeed. MacOS X can safely be considered the
>> > most potent superset of all platforms.
>> That may or may not be true. Basing development too strongly on any
>> one platform generally ends up being to the detriment of
>> cross-platform behaviour. It's like writing a class hierarchy with
>> the superclass being a particular concrete case.
>>  
>> I do worry occasionally about the increasing percentage of Mac OS X
>> fans in these discussions, both within Cincom and without. Not that I
>> have anything against the platform or those people - far from it -
>> but I feel that personal preference shouldn't unduly influence the
>> direction of the product. IMHO that direction should be determined by
>> current and projected revenues from the different platforms, from
>> Cincom's customers' customers. Obviously, Cincom have little chance
>> to influence the platform choices of those people - even amazingly
>> cool and accurate UI support for the wrong platform won't make them
>> switch. However, the quality of VW's UI support on the platform they
>> already use will have a significant influence on how many decide to buy.
>>  
>> IIRC I was told some years ago by Cincom that the total VW revenue
>> was around 90% Windows-based. I'd imagine that figure has changed
>> somewhat, but if it follows the percentage of users of platforms in
>> general, maybe not by much.
>>  
>> In the last 5 years or so most new platform-specific VW development
>> effort seems to have been expended on the Mac, and that actually
>> makes sense to me. Linux isn't much of a market in terms of people
>> actually paying for products. The (commercial) Windows world has
>> stayed largely in XP, so business apps have been able to survive
>> without a Vista L&F. (Which gives rise to another interesting
>> question: what is the split of VWrevenue between apps for people at
>> work, and apps for people at home?)
>>  
>> But with the coming of Windows 7, which looks likely to be a success
>> for both home and business users, and the faltering of Snow Leopard,
>> I imagine the market the majority of VW apps will be selling into
>> will be Windows 7. It would be nice to see some action in VW
>> development in that direction (ribbon, multitouch...), on top of the
>> things that are de rigeur on all platforms (alpha, antialiasing...).
>>  
>> All the best,
>> Steve
>>  
>>  
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>  
>
> --
> Dennis Smith                         +1 416.798.7948
> Cherniak Software Development Corporation   Fax: +1 416.798.0948
> 509-2001 Sheppard Avenue East        [hidden email]
> Toronto, ON M2J 4Z8              sip:[hidden email]
> Canada         http://www.CherniakSoftware.com
> Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP
> ------------------------------------------------------------------------
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>  

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Dennis smith-4
I wansn't commenting on a CINCOM MAC bias (although I remember the last
Solutions Conf, looked like a MAC convention:) ) -- I was commenting on
other's comments that MAC was the "superset", and by corollery the one
to try and work to).   Other than look-and-feel, I am not "personally"
unhappy with the current GUI, although we have had to make a few fixes
and enhancements -- it sure is nice to have the ABILITY to do that though !!

Michael Lucas-Smith wrote:

> In terms of support of platforms, I don't think there's any particular
> mac bias in engineering. A bunch of us use mac because it let's us run
> mac, windows and linux all on one machine. Many of us might prefer the
> mac environment, especially since it has BSD underneath it. I
> wouldn't, however, say that cocoa widgets have a particular advantage
> over windows widgets.
>
> Michael
>
> Dennis Smith wrote:
>> It may be interesting to note that many people IN the computer
>> business like the MAC,
>> but our experience with our clients is that in about 300 (+/-) I know
>> of only about 3 who wanted
>> to use MAC's to access our VW-based applications -- the rest wanted
>> Windows.
>>
>> MAC may be great, I don't have the luxury as my job is to provide
>> framework and applications for out
>> end users so I use Windows, and need to keep up with the releases too
>> (even Vista).
>>
>> Given the small number of MAC users, we don't provide a MAC version
>> of our apps, we let them
>> use either Windows on a VM or some terminal-services-like entity --
>> so at least from our perspective
>> windows is pretty much 100% of our deployments.
>>
>> I have no problem with CINCOM doing a better MAC, so long as things
>> are not driven by MAC.
>>
>> That said - up-to-date looks and feel is important on ALL fronts
>> (MAC, Windows, ...) -- so I would like to
>> see some attention there.
>>
>>
>> Steven Kelly wrote:
>>> Andre Schnoor wrote:
>>> >Am 29.11.2009 um 10:43 schrieb Antony Blakey:
>>> >> Another important choice is to start with OSX, not with Windows
>>> or >> GTK as your baseline.
>>> >
>>> > Indeed. MacOS X can safely be considered the
>>> > most potent superset of all platforms.
>>> That may or may not be true. Basing development too strongly on any
>>> one platform generally ends up being to the detriment of
>>> cross-platform behaviour. It's like writing a class hierarchy with
>>> the superclass being a particular concrete case.
>>>  
>>> I do worry occasionally about the increasing percentage of Mac OS X
>>> fans in these discussions, both within Cincom and without. Not that
>>> I have anything against the platform or those people - far from it -
>>> but I feel that personal preference shouldn't unduly influence the
>>> direction of the product. IMHO that direction should be determined
>>> by current and projected revenues from the different platforms, from
>>> Cincom's customers' customers. Obviously, Cincom have little chance
>>> to influence the platform choices of those people - even amazingly
>>> cool and accurate UI support for the wrong platform won't make them
>>> switch. However, the quality of VW's UI support on the platform they
>>> already use will have a significant influence on how many decide to
>>> buy.
>>>  
>>> IIRC I was told some years ago by Cincom that the total VW revenue
>>> was around 90% Windows-based. I'd imagine that figure has changed
>>> somewhat, but if it follows the percentage of users of platforms in
>>> general, maybe not by much.
>>>  
>>> In the last 5 years or so most new platform-specific VW development
>>> effort seems to have been expended on the Mac, and that actually
>>> makes sense to me. Linux isn't much of a market in terms of people
>>> actually paying for products. The (commercial) Windows world has
>>> stayed largely in XP, so business apps have been able to survive
>>> without a Vista L&F. (Which gives rise to another interesting
>>> question: what is the split of VWrevenue between apps for people at
>>> work, and apps for people at home?)
>>>  
>>> But with the coming of Windows 7, which looks likely to be a success
>>> for both home and business users, and the faltering of Snow Leopard,
>>> I imagine the market the majority of VW apps will be selling into
>>> will be Windows 7. It would be nice to see some action in VW
>>> development in that direction (ribbon, multitouch...), on top of the
>>> things that are de rigeur on all platforms (alpha, antialiasing...).
>>>  
>>> All the best,
>>> Steve
>>>  
>>>  
>>> ------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> vwnc mailing list
>>> [hidden email]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>>  
>>
>> --
>> Dennis Smith                                  +1 416.798.7948
>> Cherniak Software Development Corporation   Fax: +1 416.798.0948
>> 509-2001 Sheppard Avenue East        [hidden email]
>> Toronto, ON M2J 4Z8              sip:[hidden email]
>> Canada                     http://www.CherniakSoftware.com
>> Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>  
>

--
Dennis Smith                         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Eliot Miranda-2
In reply to this post by Steven Kelly


On Sun, Nov 29, 2009 at 12:20 PM, Steven Kelly <[hidden email]> wrote:
Andre Schnoor wrote:
>Am 29.11.2009 um 10:43 schrieb Antony Blakey:
>> Another important choice is to start with OSX, not with Windows or 
>> GTK as your baseline.
>
> Indeed. MacOS X can safely be considered the
> most potent superset of all platforms.
That may or may not be true. Basing development too strongly on any one platform generally ends up being to the detriment of cross-platform behaviour. It's like writing a class hierarchy with the superclass being a particular concrete case.

I don't think that's Andre's point.  I think he wants to choose the most flexible and performant platform to define a baseline set of facilities, i.e. to set a high bar.  On Windows and especially Linix that may require lots of support.  But far worse would be to define baseline datatypes that can't handle the Mac.  Remember the Mac supports non-integral pixel formats and has a very powerful rendering engine that is used routinely in the user interface.

If you look at the history of both the VW socket implementation and chameleon view (multiple looks) I think you'll see that defining a common subset has led to underperformant APIs.  Setting a high bar by using Mac as a baseline shouldn't harm Windows; instead it should set the stage for when Windows' imaging model catches up with the Mac.

But the most important thing is to get the plumbing out of the VM where it can't be readily extended, and where OO techniques can't be applied to create a polymorphic implementation of a common set of facilities (i.e. a common imaging model implemented across necessarily different platform substrates).

I also think that Sam with Widgetry and Vassili in Newspeak have demonstrated that having emulated widgets and native widgets in the same framework is doable.  And for that you get to discard the event queue road block in the VM and hook up to native event pumps.  What would make that much easier is throwing away my overengineered and underperformant threaded FFI in place of David Simmons' architecture that I've recently implemented in Squeak.   But that can be done independently in parallel.

That'll be a huge step towards a much smaller much more focussed VM which doesn't get in the way of APIs and concentrates on providing effective fast and simple access to them.


 
I do worry occasionally about the increasing percentage of Mac OS X fans in these discussions, both within Cincom and without. Not that I have anything against the platform or those people - far from it - but I feel that personal preference shouldn't unduly influence the direction of the product. IMHO that direction should be determined by current and projected revenues from the different platforms, from Cincom's customers' customers. Obviously, Cincom have little chance to influence the platform choices of those people - even amazingly cool and accurate UI support for the wrong platform won't make them switch. However, the quality of VW's UI support on the platform they already use will have a significant influence on how many decide to buy.
 
IIRC I was told some years ago by Cincom that the total VW revenue was around 90% Windows-based. I'd imagine that figure has changed somewhat, but if it follows the percentage of users of platforms in general, maybe not by much.
 
In the last 5 years or so most new platform-specific VW development effort seems to have been expended on the Mac, and that actually makes sense to me. Linux isn't much of a market in terms of people actually paying for products. The (commercial) Windows world has stayed largely in XP, so business apps have been able to survive without a Vista L&F. (Which gives rise to another interesting question: what is the split of VWrevenue between apps for people at work, and apps for people at home?)
 
But with the coming of Windows 7, which looks likely to be a success for both home and business users, and the faltering of Snow Leopard, I imagine the market the majority of VW apps will be selling into will be Windows 7. It would be nice to see some action in VW development in that direction (ribbon, multitouch...), on top of the things that are de rigeur on all platforms (alpha, antialiasing...).
 
All the best,
Steve
 
 

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Andre Schnoor
In reply to this post by Steven Kelly

Am 29.11.2009 um 21:20 schrieb Steven Kelly:

IMHO that direction should be determined by current and projected revenues from the different platforms, from Cincom's customers' customers.

Unfortunately this is a hen-and-egg problem. A platform needs to be supported well before it can generate revenue. 

For example, the revenue from our products is roughly 50% Mac 50% Windows. If we hadn't invested enormous effort in a much better platform integration on the Mac a couple years ago, we would probably see 10% Mac vs. 90% Windows revenue today (and even think that is normal!).

There is more to success than market share of a target platform. Despite Dolphin being an excellently engineered 100% Windows product, we all know it didn't make it. True cross-platform capability was and still is the competitive advantage of Cincom Smalltalk. If a product claims to be cross-platform (which IMO is a great USP), it should support all platforms equally well. 

But with the coming of Windows 7, which looks likely to be a success for both home and business users, and the faltering of Snow Leopard, I imagine the market the majority of VW apps will be selling into will be Windows 7.

Faltering? I don't think so. Snow Leopard is an update/patch only. The overall installation base of MacOS X is still growing.

Most VW installations on a Mac are used for development at this time (although I believe this will slowly change). This however still makes it a major platform: Developers are Cincom's immediate customers.

BTW: You should not worry about the increasing number of OSX fans. It's only natural that, facing the limited engineering resources at Cincom, we're all a bit jealous of the respective other customer's prefered platform ;-) 

BTW2: Thanks to our enhanced OSX VM, development on the Mac became such an enjoyable task, we moved almost 99% of all cross-platform development to the Mac. 

Andre


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Andre Schnoor
In reply to this post by Eliot Miranda-2

Am 29.11.2009 um 21:55 schrieb Eliot Miranda:

> I don't think that's Andre's point.  I think he wants to choose the  
> most flexible and performant platform to define a baseline set of  
> facilities, i.e. to set a high bar.

That's true.

> Setting a high bar by using Mac as a baseline shouldn't harm  
> Windows; instead it should set the stage for when Windows' imaging  
> model catches up with the Mac.

Exactly my point. Thanks for clarifying this.

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Andre Schnoor
In reply to this post by Eliot Miranda-2

Am 29.11.2009 um 21:55 schrieb Eliot Miranda:

And for that you get to discard the event queue road block in the VM and hook up to native event pumps.  What would make that much easier is throwing away my overengineered and underperformant threaded FFI in place of David Simmons' architecture that I've recently implemented in Squeak.   But that can be done independently in parallel.

That'll be a huge step towards a much smaller much more focussed VM which doesn't get in the way of APIs and concentrates on providing effective fast and simple access to them.

I absolutely agree, but, at least on the Mac this would need a natively multi-threaded VM, as all GUI code is required to run on the thread that owns the event loop. This can not be achieved with green threads.

Andre


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Eliot Miranda-2


On Sun, Nov 29, 2009 at 3:33 PM, Andre Schnoor <[hidden email]> wrote:

Am 29.11.2009 um 21:55 schrieb Eliot Miranda:

And for that you get to discard the event queue road block in the VM and hook up to native event pumps.  What would make that much easier is throwing away my overengineered and underperformant threaded FFI in place of David Simmons' architecture that I've recently implemented in Squeak.   But that can be done independently in parallel.

That'll be a huge step towards a much smaller much more focussed VM which doesn't get in the way of APIs and concentrates on providing effective fast and simple access to them.

I absolutely agree, but, at least on the Mac this would need a natively multi-threaded VM, as all GUI code is required to run on the thread that owns the event loop. This can not be achieved with green threads.



Andre



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Steven Kelly
In reply to this post by Steven Kelly
[hidden email] wrote:
> Am 29.11.2009 um 21:20 schrieb Steven Kelly:
>> IMHO that direction should be determined by current
>> and projected revenues from the different platforms
>
> Unfortunately this is a hen-and-egg problem. A platform
> needs to be supported well before it can generate revenue. 

That's why I said current _and projected_ revenue: you should certainly factor in the possibility of increased revenue if you improve platform X - that's the whole point of this discussion.  

The question then is: if Cincom spend $10k on Mac, does that increase Cincom income more than spending $10k on Windows? For that to be true, given the current market share, Mac work would have to be ten times more effective at increasing revenue. I find that unlikely.

Eliot Miranda wrote:

> Steven Kelly wrote:
>> Andre Schnoor wrote:
>>> Indeed. MacOS X can safely be considered the
>>> most potent superset of all platforms.
>>
>> That may or may not be true. Basing development too
>> strongly on any one platform generally ends up being
>> to the detriment of cross-platform behaviour. It's
>> like writing a class hierarchy with the superclass
>> being a particular concrete case.
>
> I don't think that's Andre's point.  I think he wants
> to choose the most flexible and performant platform to
> define a baseline set of facilities, i.e. to set a
> high bar.  On Windows and especially Linix that may
> require lots of support.  But far worse would be to
> define baseline datatypes that can't handle the Mac.  

With infinite resources, and a primary goal of superlative support of all platforms, that's correct. With resource constraints and a primary goal of long term revenue maximization, it looks far worse.

Besides, the Mac isn't just a superset of the other platforms - AFAIU it has several fairly fundamental differences in the way it works. In that situation, you generally find that either the "odd man out" suffers compared to the other platforms, or that if you base your fundamentals on the "odd man out", all the other platforms suffer. That suffering is reflected in making development for those platforms harder (both at Cincom and customers), and/or suboptimal results in the UI. In this case, basing the fundamentals on the Mac would lead to higher costs and lower revenues on ~90% of PCs, with corresponding upsides on <10% of PCs.

Windows 7 is already passing Mac OS X (all versions) in market share:
www.pcworld.com/article/183325/windows_7_sales_beat_mac_os_x_market_share.html

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Andre Schnoor

Am 30.11.2009 um 11:19 schrieb Steven Kelly:

> Besides, the Mac isn't just a superset of the other platforms -  
> AFAIU it has several fairly fundamental differences in the way it  
> works.

Exactly. These differences account for the horrid diffculties and ugly  
workarounds needed to implement the Mac VM on top of a Windows-
inspired API. It would be much simpler the other way round. I worked  
on both the MacOS X VM and the Windows VM for a long time ;-)

These fundamental differences don't conflict with the design of an API  
(primitives in this case) that could be used on Windows, Linux, MacOS  
X, X11 and others alike. Many higher-level features not supported on a  
particular platform can be replaced by a simple NOP (lockFocus/
unlockFocus, for example) or by equivalent substitutes.

> In this case, basing the fundamentals on the Mac would lead to  
> higher costs and lower revenues on ~90% of PCs, with corresponding  
> upsides on <10% of PCs.

Hm. I guess we are probably talking about different things.

Basing the API design (primitives, frameworks) on the most complete  
feature set available today doesn't have the slightest influence on  
the appearance or performance under Windows. It just provides a  
unified interface that works on all platforms without discriminating  
against any of them. This is what a cross-platform product ought to be.

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Steven Kelly
In reply to this post by Steven Kelly
[hidden email] wrote:
Steven Kelly wrote:
> > In this case, basing the fundamentals on the Mac would lead to
> > higher costs and lower revenues on ~90% of PCs, with corresponding
> > upsides on <10% of PCs.
>
> Hm. I guess we are probably talking about different things.

Maybe. I was relying on what Eliot said would happen, if the basis for
VW graphics became the Mac:

> On Windows and especially Linix that may
> require lots of support.  

You and Eliot have far more experience than I do in messing around with
graphics in the VM. If I understand Eliot correctly, reimplementing all
the VMs (or even VM/VI boundary) to make them work like a Mac would
result in increased expenditure per unit change on Windows and Linux
(but decreased on Mac). It would of course also be a major project,
which at best would leave the situation unchanged for Windows users. It
could of course have the best long-term effect, but it's hard to see how
that could be the case if supporting Windows and Linux would become
harder work for Cincom.
 
As for being able to achieve the same appearance and performance on
Windows, whether the fundamentals are Mac-based or the current ones, I
don't know. Certainly it seems to be the case that you feel pain on the
Mac because VW's current fundamentals are different from the Mac's. Even
if the Mac way is more conceptually sound, translating to a 'stupid'
Windows graphics world is going to result in problems of speed and
accuracy, compared with working natively in the Windows world.

Maybe part of the confusion is between which things are just suboptimal
in the current VW graphics approach, and which are not Mac-friendly. I'm
all for moving away from direct writes to graphic contexts, gc copying
etc. (as VW seems to be doing).

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Andre Schnoor

Am 30.11.2009 um 16:17 schrieb Steven Kelly:

> Even if the Mac way is more conceptually sound, translating to a
> 'stupid' Windows graphics world is going to result in problems of
> speed and accuracy, compared with working natively in the Windows  
> world.

There is not much to be "translated to another world", except rounding  
floats to integers and stuff along that line. When talking about API,  
I mean parameters, result types and behavior of VM primitives (or  
equivalent FFI calls), and the way they should be used by Smalltalk  
code (see below). The underpinnings are kept unchanged, 100% native as  
they are now.

> I'm all for moving away from direct writes to graphic contexts, gc
> copying etc. (as VW seems to be doing).

Exactly ;-) This suggested change happens to be "Mac friendly" by  
accident, because MacOS X native graphics require that sort of clean  
drawing transactions (which btw make them flicker-free).

If these issues were sorted out properly, a VW application would be  
truly portable across all platforms, including all its bells an  
whistles (which is currently not the case).

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Eliot Miranda-2
In reply to this post by Steven Kelly


On Mon, Nov 30, 2009 at 7:17 AM, Steven Kelly <[hidden email]> wrote:
Steven Kelly wrote:
> > In this case, basing the fundamentals on the Mac would lead to
> > higher costs and lower revenues on ~90% of PCs, with corresponding
> > upsides on <10% of PCs.
>
> Hm. I guess we are probably talking about different things.

Maybe. I was relying on what Eliot said would happen, if the basis for
VW graphics became the Mac:

> On Windows and especially Linix that may
> require lots of support.

You and Eliot have far more experience than I do in messing around with
graphics in the VM. If I understand Eliot correctly, reimplementing all
the VMs (or even VM/VI boundary) to make them work like a Mac would
result in increased expenditure per unit change on Windows and Linux
(but decreased on Mac). It would of course also be a major project,
which at best would leave the situation unchanged for Windows users. It
could of course have the best long-term effect, but it's hard to see how
that could be the case if supporting Windows and Linux would become
harder work for Cincom.

That's not my point :)  My point is twofold.  First that implementing cross-platform abstractions in the VM is a really bad idea because the VM, being C, and having to provide backward-compatibility with older images simply can't evolve fast enough and instead one should expend resources on the VM's FFI so that the FFI does not prevent one from accessing platform APIs.  Second, when choosing a cross-platform abstraction it is better to aim at implementing a superset rather tan a common subset because the common subset is too limiting. If one finds (as I suspect but can't swear) that a particular platform's capabilities (e.g. Mac) is a strict superset of another platform's (e.g. Windows) one should choose the strict superset.

I'm guessing that the strict superset should still be able to support the datatypes in the subset and so, for those capabilities the weaker platform provides, performance ill be no worse.  Only when emulating facilities not available on the weaker platform would one expect performance to be poor, but by definition one wouldn't have to use those facilities to be faithful to the weaker platform, because these facilities are unavailable natively and therefore not part of its look and feel.



As for being able to achieve the same appearance and performance on
Windows, whether the fundamentals are Mac-based or the current ones, I
don't know. Certainly it seems to be the case that you feel pain on the
Mac because VW's current fundamentals are different from the Mac's. Even
if the Mac way is more conceptually sound, translating to a 'stupid'
Windows graphics world is going to result in problems of speed and
accuracy, compared with working natively in the Windows world.

Maybe part of the confusion is between which things are just suboptimal
in the current VW graphics approach, and which are not Mac-friendly. I'm
all for moving away from direct writes to graphic contexts, gc copying
etc. (as VW seems to be doing).

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Steven Kelly
In reply to this post by Steven Kelly
Eliot Miranda wrote 30 November 2009 22:51:
> implementing cross-platform abstractions in the VM is a
> really bad idea because the VM, being C, and having to
> provide backward-compatibility with older images simply
> can't evolve fast enough and instead one should expend
> resources on the VM's FFI so that the FFI does not
> prevent one from accessing platform APIs.  

A major change in VM graphics support would be a new major number, so there would be no expectation of backwards compatibility. Some of the 7.* VMs have broken backward compatibility anyway in some way.

A faster FFI would of course be useful in any case - although looking forward on Windows the speed needs are more in calling .NET code or SOAP than DLLs.

> Second, when choosing a cross-platform abstraction it is
> better to aim at implementing a superset rather tan a
> common subset because the common subset is too limiting.

Of course. I suppose we need to be more concrete here about what we are discussing. Graphics and UI have been the topics so far, and that covers say three levels:

1) low level - e.g. can pixels have alpha
2) 'advanced' functionality - e.g. gradient fills
3) GUI widgets

IIRC VW hasn't moved an inch on the first two levels in all the time it's existed(!). Many basic bugs are still uncorrected (e.g. ellipse outlines with width 2 being seriously ugly, ellipse fills being off by one pixel).

Level 3 'chameleon switching' used to be one of the big plus points of VW, but nowadays (as Mark Plas pointed out) we don't even know what a widget should look like on a given platform, because native apps from the platform provider don't use them. 10 years ago users demanded pixel-faithful emulation of Windows widgets, and Cincom (OS/PPD/PP) could make many people very happy with a new L&F for a new Windows version. Nowadays, I still want Vista and Win7 L&Fs, but I doubt they're going to have such an effect on user satisfaction.

I think a working grid or ribbon, using platform colours but otherwise the same on all platforms, would have a bigger effect. Other than that, to make the users happy these days, each application needs to add its own cool effects. That's really bad news for reuse, but there's little we can do. Worse, cool effects all require new facilities from levels 1 and 2, so in the current VW we either do without or each spend massive amounts of our own effort on achieving them in some roundabout way.

I'm delighted to see the work on Cairo and OpenGL, and hope functionality like that makes its way into the base graphics system of VW soon. IMHO having bolt-on DLLs etc. doesn't work for the cross platform story: downloading and maybe even compiling 3rd party DLLs for several different platforms is acceptable for preview code, but not in production - at least not for a core component of the system like graphics.

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Eliot Miranda-2


On Mon, Nov 30, 2009 at 2:04 PM, Steven Kelly <[hidden email]> wrote:
Eliot Miranda wrote 30 November 2009 22:51:
> implementing cross-platform abstractions in the VM is a
> really bad idea because the VM, being C, and having to
> provide backward-compatibility with older images simply
> can't evolve fast enough and instead one should expend
> resources on the VM's FFI so that the FFI does not
> prevent one from accessing platform APIs.  

A major change in VM graphics support would be a new major number, so there would be no expectation of backwards compatibility. Some of the 7.* VMs have broken backward compatibility anyway in some way.

Right.  But from then on any desire to fix or extend functionality would be frustrated by that that was in the VM.  If everything is up in the image one can issue a patch.  if it is in the VM it has to be backward-compatible until the next major release number.


A faster FFI would of course be useful in any case - although looking forward on Windows the speed needs are more in calling .NET code or SOAP than DLLs.

An FFI doesn't have to preclude .NET calls.  SOAP is indeed something else.
 

> Second, when choosing a cross-platform abstraction it is
> better to aim at implementing a superset rather tan a
> common subset because the common subset is too limiting.

Of course. I suppose we need to be more concrete here about what we are discussing. Graphics and UI have been the topics so far, and that covers say three levels:

1) low level - e.g. can pixels have alpha
2) 'advanced' functionality - e.g. gradient fills
3) GUI widgets

IIRC VW hasn't moved an inch on the first two levels in all the time it's existed(!). Many basic bugs are still uncorrected (e.g. ellipse outlines with width 2 being seriously ugly, ellipse fills being off by one pixel).

and IMO one of the causes of there being no movement on 1) or 2) is that some of the functionality and all of the API plumbing is in the VM.
 

Level 3 'chameleon switching' used to be one of the big plus points of VW, but nowadays (as Mark Plas pointed out) we don't even know what a widget should look like on a given platform, because native apps from the platform provider don't use them. 10 years ago users demanded pixel-faithful emulation of Windows widgets, and Cincom (OS/PPD/PP) could make many people very happy with a new L&F for a new Windows version. Nowadays, I still want Vista and Win7 L&Fs, but I doubt they're going to have such an effect on user satisfaction.

I think a working grid or ribbon, using platform colours but otherwise the same on all platforms, would have a bigger effect. Other than that, to make the users happy these days, each application needs to add its own cool effects. That's really bad news for reuse, but there's little we can do. Worse, cool effects all require new facilities from levels 1 and 2, so in the current VW we either do without or each spend massive amounts of our own effort on achieving them in some roundabout way.

Right.  Again the VM implementation is a horrible bottle-neck.

I think we're in violent agreement so I'll shut up :)

I'm delighted to see the work on Cairo and OpenGL, and hope functionality like that makes its way into the base graphics system of VW soon. IMHO having bolt-on DLLs etc. doesn't work for the cross platform story: downloading and maybe even compiling 3rd party DLLs for several different platforms is acceptable for preview code, but not in production - at least not for a core component of the system like graphics.

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Travis Griggs-3
In reply to this post by Steven Kelly

On Nov 30, 2009, at 2:04 PM, Steven Kelly wrote:

> I'm delighted to see the work on Cairo and OpenGL, and hope  
> functionality like that makes its way into the base graphics system  
> of VW soon. IMHO having bolt-on DLLs etc. doesn't work for the cross  
> platform story: downloading and maybe even compiling 3rd party DLLs  
> for several different platforms is acceptable for preview code, but  
> not in production - at least not for a core component of the system  
> like graphics.

I'm not entirely sure I'm understanding correctly Steven, apologies if  
I'm responding to a misinterpretation of your text.

 From a low level point of view, what you see in preview, is the basic  
approach we *will* stick to with Cairo. We provide a precompiled DLL.  
You don't have to download it, you don't have to compile it. It's  
placed right next to your VM, so you don't even have to move it, other  
than if you move the VM, you have to move the dll along with it.

The CairoGraphics package might get integrated directly into  
visual.im, or even base.im, who knows. But the C library will not be  
compiled into the VM. Cairo is licensed under both LGPL and MPL. These  
allow us to do what ever we want with them, make money, change, etc.  
We have to make any changes we apply to the compile publicly available  
(which we haven't, but we have contributed our end-to-end build  
instructions back to said community). *IF* we were to link to the VM,  
we would have to make that publicly available as well.

The drawback of this, is that you get away from the "it's just one  
executable" model. Which we didn't have anyway because of the image.

--
Travis Griggs
Objologist
"It had better be a pretty good meeting, to be better than no meeting
at all" - Boyd K Packer


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Travis Griggs-3

On Nov 30, 2009, at 3:42 PM, Travis Griggs wrote:

>
> On Nov 30, 2009, at 2:04 PM, Steven Kelly wrote:
>
>> I'm delighted to see the work on Cairo and OpenGL, and hope
>> functionality like that makes its way into the base graphics system
>> of VW soon. IMHO having bolt-on DLLs etc. doesn't work for the cross
>> platform story: downloading and maybe even compiling 3rd party DLLs
>> for several different platforms is acceptable for preview code, but
>> not in production - at least not for a core component of the system
>> like graphics.
>
> I'm not entirely sure I'm understanding correctly Steven, apologies if
> I'm responding to a misinterpretation of your text.
>
> From a low level point of view, what you see in preview, is the basic
> approach we *will* stick to with Cairo. We provide a precompiled DLL.
> You don't have to download it, you don't have to compile it. It's
> placed right next to your VM, so you don't even have to move it, other
> than if you move the VM, you have to move the dll along with it.
>
> The CairoGraphics package might get integrated directly into
> visual.im, or even base.im, who knows. But the C library will not be
> compiled into the VM. Cairo is licensed under both LGPL and MPL. These
> allow us to do what ever we want with them, make money, change, etc.
> We have to make any changes we apply to the compile publicly available
> (which we haven't, but we have contributed our end-to-end build
> instructions back to said community). *IF* we were to link to the VM,
> we would have to make that publicly available as well.
>
> The drawback of this, is that you get away from the "it's just one
> executable" model. Which we didn't have anyway because of the image.


Alan pointed out to me that MPL actually might allow us to link the  
cairo libs with the VM. Would have to do some more research, but it  
might be possible. Still not sure it's desirable from all pov, but  
it's interesting.

--
Travis Griggs
Objologist
Light travels faster than sound. This is why some people appear bright  
until you hear them speak...




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Steven Kelly
In reply to this post by Steven Kelly
Travis Griggs wrote 01 December 2009 01:42:

> On Nov 30, 2009, at 2:04 PM, Steven Kelly wrote:
>
> > I'm delighted to see the work on Cairo and OpenGL, and hope
> > functionality like that makes its way into the base graphics system
> > of VW soon. IMHO having bolt-on DLLs etc. doesn't work for the cross
> > platform story: downloading and maybe even compiling 3rd party DLLs
> > for several different platforms is acceptable for preview code, but
> > not in production - at least not for a core component of the system
> > like graphics.
>
> From a low level point of view, what you see in preview, is the basic
> approach we *will* stick to with Cairo. We provide a precompiled DLL.
> You don't have to download it, you don't have to compile it.

That's certainly better than having to find and download Cairo libs for
all the platforms, and make sure they all work the same. Having updates
to Cairo libs coming via a similar process to updates to VMs would seem
about right for most cases.

> The CairoGraphics package might get integrated directly into
> visual.im, or even base.im, who knows. But the C library will not be
> compiled into the VM.

:-(.

> The drawback of this, is that you get away from the "it's just one
> executable" model. Which we didn't have anyway because of the image.

At least on Windows we do, with reshacker and visual.exe.

> Alan pointed out to me that MPL actually might allow us to link the
> cairo libs with the VM. Would have to do some more research, but it
> might be possible. Still not sure it's desirable from all pov, but
> it's interesting.

:-). It would certainly bear looking at!

Do you intend for the VM to continue to do drawing the old way (e.g. GDI
on Windows), so Cairo will remain an optional add-on - quite possibly
requiring different calls to use?

Or since Cairo is a superset of the VM's current graphics support, and
following similar logic to Eliot and Andre earlier, would it be
relatively easy (or at least efficient) to completely replace the
current graphics primitives with Cairo?

Or would it be best to take this opportunity to rewrite the whole of the
GraphicsContext tree? Either just with a more modern approach and Cairo
primitives, or to move many things up from the VM to the image?

Cheers,
Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Platform priorities

Terry Raymond
In reply to this post by Travis Griggs-3

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Travis Griggs
> Sent: Monday, November 30, 2009 6:42 PM
> To: VWNC List
> Subject: Re: [vwnc] Platform priorities
>
>
> On Nov 30, 2009, at 2:04 PM, Steven Kelly wrote:
>
> > I'm delighted to see the work on Cairo and OpenGL, and hope
> > functionality like that makes its way into the base graphics system
> > of VW soon. IMHO having bolt-on DLLs etc. doesn't work for the cross
> > platform story: downloading and maybe even compiling 3rd party DLLs
> > for several different platforms is acceptable for preview code, but
> > not in production - at least not for a core component of the system
> > like graphics.
>
> I'm not entirely sure I'm understanding correctly Steven, apologies if
> I'm responding to a misinterpretation of your text.
>
>  From a low level point of view, what you see in preview, is the basic
> approach we *will* stick to with Cairo. We provide a precompiled DLL.
> You don't have to download it, you don't have to compile it. It's
> placed right next to your VM, so you don't even have to move it, other
> than if you move the VM, you have to move the dll along with it.
>
> The CairoGraphics package might get integrated directly into
> visual.im, or even base.im, who knows. But the C library will not be
> compiled into the VM. Cairo is licensed under both LGPL and MPL. These
> allow us to do what ever we want with them, make money, change, etc.
> We have to make any changes we apply to the compile publicly available
> (which we haven't, but we have contributed our end-to-end build
> instructions back to said community). *IF* we were to link to the VM,
> we would have to make that publicly available as well.
>
> The drawback of this, is that you get away from the "it's just one
> executable" model. Which we didn't have anyway because of the image.

Except for those of us who compress the image and put it into the exe.

> --
> Travis Griggs
> Objologist
> "It had better be a pretty good meeting, to be better than no meeting
> at all" - Boyd K Packer
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
123