[vwnc] Platform priorities

OK, Paul, that makes a lot of sense.  I like the analogy, too.  That wasn’t exactly the way I perceived what happened, but that’s certainly a reasonable description of the result.

Now, while that explains what happened to one solution to improve the GUI, let’s address the thread.  Is there a feasible, coordinated approach that covers all of the desired goals:  improving Wrapper, better GUI capabilities (alpha, anti-aliasing, fonts), improved tools, and so on?  You indicated you like submitting fixes and seeing them added;  my luck with that seems more limited.

Since we all seem to want to complain, and we all know Cincom’s resources are tight, perhaps we should ask the question differently:  What could be changed to helps us contribute solutions (and get them included) to move things along?  What is Cincom willing to do to support that?

In simple terms...

It is infeasible by common approach.

The way to eat an elephant is...one bite at a time. The Widgetry elephant couldn't be swallowed in one sitting even with several years of preparation. The problem wasn't that Sames needed more time or encouragement, but that increasingly Cincom's customers were expected to swallow really-really hard and Cincom finally came to realize that they wouldn't. End result was that Cincom practically starved itself figuring out how to consume that damn elephant in one sitting and decided to find something else to eat instead.

In general...

Focus on finding solutions to the small problems at hand; the bigger problems work themselves out over time and opportunities become easier to exploit. In an environment of Liberty, you don't need to risk for grand ambitions because you have the daily satisfaction of having taken one step closer in a direction that was demonstrably correct and practical.

Furthermore...

I want to see Cincom developers anxious to fix problems and incorporate solutions instead of being stressed by a list of scheduled requirements. The best code often comes from a useful but complicated body of code that incrementally evolved into a work of art--to a form not originally anticipated. Bad code comes from replacing one complicated mass of code with another with some new forced twist--and then needing to support both. Bad code happens from a legacy of resisting refinements to "working" code.

When I send a fix to Cincom, I want it released in product to customers within a month or two (this is why open-source works; not because it is "free"). There is a cost involved in sending code to Cincom instead of just hacking a workaround into place. It is cheaper to just fix the problem here and hope Cincom never changes code in a way that breaks a workaround. For several years now, that has unfortunately been the most effective approach. Fix it and forget about wasting time sharing or even communicating the fix. I'd encourage a system that makes it more practical for me to share fixes with more than an excuse in return.

Cincom doesn't need to eat the entire elephant, but they do have to encourage others to join them at the table and offer them a carving knife and a fork.

Paul Baumann 

From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Tuesday, December 01, 2009 2:27 PM
To: [hidden email]; [hidden email]; [hidden email]
Subject: Re: [vwnc] Platform priorities

I’ve spent the past couple of days reading through this entire list.  In terms of GUI upgrades, especially for native widgets, could someone please explain why that is really so infeasible?  I must be dense, so could you use small words?  J  While it may take a release or two to get there, it seems that we have all of the pieces [or thought experiments] in place to do it:

1. Move the GUI out of the VM.  Use Cairo as the base.  This permits completely headless images.
2. For native widgets, do it all by DLL, even direct access to X11, Quartz, or whatnot.
3. To facilitate this, resurrect Widgetry or at least move to something with cleaner structural separation.
1. A pane could be an emulated pane or a native pane.
2. Native artists follow, which interface to the DLL calls to do what you want.
3. Native agents and event interaction could be facilitated by some of the multi-threaded VM discussions (such as that one by Eliot).
4. Build hierarchical and peer packages, so that you can move [gradually] to full implementation while providing immediate functionality where you can.
4. I would add:  give serious thought on how to dynamically memory-map segments to handle the chameleon effect (that is, map on reference without saving).

I think one objective is to be able to do this polymorphically:  native and emulated widgets on the same window.  It can’t be such a hard thing, since an emulated widget is really nothing more than a direct draw capability to the underlying window canvas.  All the drawing primitives ultimately do that, so the adjustments should come naturally simply by moving behavior into the image.  Where we have “LookPolicy” we’d add “NativeUIPolicy” or something.

I’m not denying that this wouldn’t take some significant work, but at this stage it could at least be planned or prototyped.

IMPORTANT NOTICE

Email from OOCL is confidential and may be legally privileged.  If it is not

intended for you, please delete it immediately unread.  The internet

cannot guarantee that this communication is free of viruses, interception

or interference and anyone who communicates with us by email is taken

to accept the risks in doing so.  Without limitation, OOCL and its affiliates

accept no liability whatsoever and howsoever arising in connection with

the use of this email.  Under no circumstances shall this email constitute

a binding agreement to carry or for provision of carriage services by OOCL,

which is subject to the availability of carrier's equipment and vessels and

the terms and conditions of OOCL's standard bill of lading which is also

available at http://www.oocl.com.

IMPORTANT NOTICE

Email from OOCL is confidential and may be legally privileged.  If it is not

intended for you, please delete it immediately unread.  The internet

cannot guarantee that this communication is free of viruses, interception

or interference and anyone who communicates with us by email is taken

to accept the risks in doing so.  Without limitation, OOCL and its affiliates

accept no liability whatsoever and howsoever arising in connection with

the use of this email.  Under no circumstances shall this email constitute

a binding agreement to carry or for provision of carriage services by OOCL,

which is subject to the availability of carrier's equipment and vessels and

the terms and conditions of OOCL's standard bill of lading which is also

available at http://www.oocl.com.

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

I’ve recently had a few days’ coding session where I had to resort to adding rather ugly hacks and duplication to get something complicated working. Followed by a second session where I refactored the published working code to get rid of the hacks and duplication, and all the ugliness disappeared and left something that worked and was understandable.

That really brought home to me how true is the old adage “make it work, make it right, make it fast”. I think that would also apply in this situation. There’s a mass of existing VW graphics code, some within Cincom but most outside, so there’s no real possibility for starting from a clean slate. As Paul says, this is an elephant that must be eaten one bite at a time – but I truly believe it MUST be eaten. We can’t put this off because we know that what we will have in VW 8, 9 etc. is a bit messy and incomplete – (a half-eaten elephant lying around). I think both Cincom’s customers (us) and our customers are so hungry, we’ll be happier eating a messy elephant than dreaming of a perfect one.

Steve

IMPORTANT NOTICE

Email from OOCL is confidential and may be legally privileged.  If it is not

intended for you, please delete it immediately unread.  The internet

cannot guarantee that this communication is free of viruses, interception

or interference and anyone who communicates with us by email is taken

to accept the risks in doing so.  Without limitation, OOCL and its affiliates

accept no liability whatsoever and howsoever arising in connection with

the use of this email.  Under no circumstances shall this email constitute

a binding agreement to carry or for provision of carriage services by OOCL,

which is subject to the availability of carrier's equipment and vessels and

the terms and conditions of OOCL's standard bill of lading which is also

available at http://www.oocl.com.

IMPORTANT NOTICE

Email from OOCL is confidential and may be legally privileged.  If it is not

intended for you, please delete it immediately unread.  The internet

cannot guarantee that this communication is free of viruses, interception

or interference and anyone who communicates with us by email is taken

to accept the risks in doing so.  Without limitation, OOCL and its affiliates

accept no liability whatsoever and howsoever arising in connection with

the use of this email.  Under no circumstances shall this email constitute

a binding agreement to carry or for provision of carriage services by OOCL,

which is subject to the availability of carrier's equipment and vessels and

the terms and conditions of OOCL's standard bill of lading which is also

available at http://www.oocl.com.