[vwnc] Does Cincom give up the Desktop ?

Hello Arden,

good to read your response. I feel there is big potential for cross- 
platform desktop applications, as these suffer a lot from the  
deficiencies of the static C/C++ world. If VW had had a more mature  
and modern UI framework earlier, flagships like the Adobe DTP line of  
products and QuarkXPress and others along that line could have been  
implemented in Smalltalk as well (for the benefit of easier  
maintenance and robustness at least - my god, Quark crashes on me  
every day and the cross-platform UI of Adobe InDesign doesn't look  
native at all).

Any application with a complex domain that doesn't require number- 
crunching would benefit from Smalltalk. If VW wants to be considered  
for new commercial projects, it needs to look more "current" at first  
sight.

  

Feedback like this helps keep the pressure on priority for this type
of work, so I invite others to weigh in on where their product
improvement priorities lie.
    

As you know, we are making rather complex multi-media desktop  
applications with a very rich GUI. These products are targeted at an  
audience with high expectations concerning usability and platform  
faithfulness. This is being successful so far, although we had to  
invest a lot of time and money building our own frameworks. Anyway,  
it's a proof of concept that it can be done.

Here's my UI wishlist:

- Cairo is great, but in order to properly integrate with Wrapper, the  
latter needs a major overhaul with respect to display refreshes and  
avoiding GC copying, etc. If you make all graphics transactional, that  
is,  display updates properly encapsulated (on a Mac: lockFocus/ 
unlockFocus), many current issues and obscurities will magically go  
away!

- Continue to support native fonts. Generic substitutes just don't cut  
it.

- Modernize the way native windows are created/linked/configured. I  
managed to do that by modifying the Mac and Windows VMs myself, but I  
think it should be supported out of the box: Tool palettes, drawers,  
sheets, real window parentship (i.e. children move together with  
parent), etc. Hint: API-wise, the Mac can safely be considered the  
superset of all platforms. If a feature isn't supported on other  
platforms, just ignore it, or subsitute it with a cheap alternative.

- Menus: Use MenuBuilder (or a more capable subclass) for all menus  
throughout the system. Get rid of old fashioned menu constructors.  
Stick to a simple, extensible API.

- Keyboard mapping: Do not assign hard-coded shortcuts to menu items,  
as these are platform-dependent. Instead, assign a symbolic key or  
action (#extendSelectionRightKey:) to a menu item and have it look up  
its current shortcut from the user's current keyboard mapping itself.  
This makes the entire system configurable and works like a charm!

Just recently I've done a lot of new work concerning keyboard mapping.  
I will submit the code soon.

One more thing about L&F policies: IMO it would make sense to  
implement a configurable L&F based on skins. If a new OS version is  
released, only the skin needs to be replaced.

Andre
_______________________________________________
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

With specific regard to Vista, there are issues if we want to make it look like Aero, which uses graphical techniques that our system currently can't do.

Alan,

  - Fonts were mentioned a couple of times

From an engineer's perspective, native fonts might seem like a minor matter of design only. Real world end users however expect to be able to use the fonts they have installed on their computer (and sometimes paid for), at least for printing and editing. 

Every detail that adds to the impression a product was "ported" from some "foreign" platform causes more buyers to decide for the competition. They feel like getting isolated, locked in a closed "incompatible" world. Once I changed our products to use Lucida Grande all over, Mac users stopped lamenting and started perceiving our work as something made for "them" (admittedly, the native menu bar was also very helpful).

Just a thought: If Pango could be enhanced to support native fonts, contributing this feature to the Pango project would probably be a good investment.

Regarding Cairo:

IMO, a full switch to Cairo would be a real achievement, if the entire Smalltalk API was based on it (including Float screen coordinates) and provided that Cairo is tightly (invisibly) packaged with VW, not shipped as some separate item.

  - There was a mention of using MenuBuilder as the only way to build menus, removing other mechanisms.

No. Of course they should be still there for backwards compatibility. My point was to consequently change the Cincom-deployed code base for the benefit of making the user interface configurable and cross-platform (which it currently isn't!). 

It cost me months of struggle to implement a very simple customer demand ("customizable keyboard shortcuts"), which is standard for almost every non-trivial desktop app. I ended up writing my own feel policies, keyboard dispatch tables and menu infrastructure. While doing that, I encountered a lot of hackish hard-wired menu code in the base image that was hard to decipher (let alone maintain).

Andre

_______________________________________________
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

Responding to various different messages in one...

 First off, thanks to everyone for the input.  We very much need ot hear from people which things they feel are important for us to be working on. You may think it's obvious that X needs to be done, but there are quite a lot of large X's that need to be done, and we still have to pick and choose between them, with limited resources.

  We certainly haven't given up on desktop development. I actually think we've done quite a bit with respect to that recently, but there's still obviously a great deal more. Updating the look and feels is something we really ought to have gotten to in this release, but didn't. With specific regard to Vista, there are issues if we want to make it look like Aero, which uses graphical techniques that our system currently can't do. Non-Aero Vista would, I think, be fairly easy, at least from what I see, because I run Vista under VMWare and it doesn't look all that different from XP.

  Supporting those kinds of graphical techniques our system can't do is also obviously important. We've been moving forward, albeit slowly, on using Cairo to provide that. We expect to continue doing so, hopefully faster. I can give you some contact numbers for people to talk to regarding our staffing.

  On a few of the specific points
 
  - Fonts were mentioned a couple of times, once regarding "ugly fonts", which I interpret to mean "anti-aliased fonts under X Windows", and once urging us to use native fonts and not use generic substitutes. I think that might be a vote against using the Pango sister package to Cairo in order to achieve the former, but maybe it means something else. Fonts in general are something we know needs work, but are a pretty major piece of work that we haven't done yet.

  - There was a mention of using MenuBuilder as the only way to build menus, removing other mechanisms.  In general terms, that sounds like the sort of thing we're reluctant to do, because it means that people's older code won't run. We can do that where it's necessary, but it has to be well motivated before we impose additional burden on customers who want to update to newer versions. It's not obvious to me from the request what the expected benefit is of disallowing the others. The poster with 3000+ canvases in production might not appreciate having to redo all the menus.

 - There was a mention of ActiveX support in ObjectStudio Classic but not in ObjectStudio 8 that makes it sound as if ObjectStudio 8 doesn't support ActiveX controls. That's not the case. ObjectStudio 8 has full support for ActiveX controls. And as of 7.7 VisualWorks also has the ability to embed ActiveX controls.

Finally, the initial message in this thread came after listening to one of Jim's podcasts, and referred both to Arden Thomas (our product manager) and his comments, but to a number of things Michael Lucas-Smith had talked about in other podcasts. I thinks it's advisable not to put so much weight on things in the podcasts. I haven't listened to it myself, but I suspect that Arden's comments focused on major items and didn't talk, for example, about the 250 or so ARs that we have in this release under the categories of GUI and tools, most of which are smaller, but still quite important. And that doesn't count things like the large amount of work on locales and internationalization. I hope that a few of our customers will find the ability of users to successfully enter and view characters in a much wider range of circumstances to be useful for desktop applications.

In general, comments in such forums shouldn't be taken as commitments, particularly comments from engineers about something being important, or easy. Unless the comment is of the form, "I have been working on and have almost finished..." then I'd call it speculation, not a basis for expecting something will necessarily be done, or that that person will be working on it.

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

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