Multi-process windows manager

-----Original Message-----
From: Ladislav Lenart [mailto:[hidden email]]
Sent: 27 March 2006 9:19
To: Stewart MacLean
Cc: 'Reinout Heeck'; 'VW NC'
Subject: Re: Multi-process windows manager

Stewart MacLean wrote:

<rant mode>

Having jumped through all sorts of hoops and grovelling around in the

bowels of the system to get my UI looking smooth and sweet (most of the

time), I second this. ("fixing Wrapper").

Out of the box, the UI appears very unprofessional with lots of flashing

and a general ugly feel to it.

I absolutely agree with you.

Take for example the TreeView. This simply does not behave correctly. To

observe go to the System Settings and expand System, and then expand

Source. Now collapse System and re-expand. Standard behaviour is to

restore the previously expanded children, it doesn't.

See the comment in TreeModel<<expand: anIndex 

       "Expand the element at anIndex if it is not expanded yet. 

       Also expand children that were expanded when this node was

contracted."

Unfortunately it is not just a TreeView.

I’ve mostly ditched the base TreeView in favour of the Aragon goodie. The implementation is a lot cleaner, and it works as expected. (even if it doesn’t support the event framework quite so well).

Recently I added #moveTo: method to ResizingSplitterView to be able to move the splitter programmatically. In order to do this, I had to teach it its position - kind of basic for such a widget one would say. And BTW have you notice how does the splitter behave when you start moving it? Its left border (in case of vertical splitter) is aligned with mouse cursor position - the thicker the splitter the bigger the move...

Yep, done something similar…only took a “few” days.

Or next great chapter I am working on right now is drag & drop - why I have to write 7 or so methods all over again for each widget in each application I want to drag in (I am in the process of removing this duplication but I think it should not be there in the first place)??? Or the silly behavior of drag & drop in the browser itself - you can start dragging only when you are selecting an object... or insufficient indication of where the drop would occur...

I’ve deliberately steered clear of this. In fact I’d like to be able to turn it off. (I sometimes inadvertently screw up my objects when inspecting in Trippy).

Or next one - UI Look and Feel. It is there to support the variation but its implementation effectively inhibits it because it is full of duplication...
We were trying to create flat (unbordered) look - but we did not succeed much...

Haven’t even considered doing that.

Or next issue that awaits for me is DoubleBufferingDisplayPolicy - it seems that it does not work properly - it seems that some invalidate messages pass through it but others don't...

I’ve had good success with this, after I applied a fix available at:

http://www.smalltalk.ru/articles/flicker-free-eng.html

Many thanks to Alex Baran & Andrei N.Sobchuck for this.

However to smooth things out completely I’ve had to work on suppression of triggered changes and even have my own “domain event” queue, as the ordering of ui events seems to get screwed up when one hits the return button quickly.

And there's much more!
(Sounds like s p a m, doesn't it ;-)

When I started out, I considered using Pollock. However on investigation

I soon realised that it had a long way to go. Given the recent comments,

I'm very glad I didn't go down that route. (Especially when I hear of

poor performance and downgraded functionality, such as non programmatic

moving of splitters).

We were considering Pollock too but have chosen not to use it due to its slowness and some bugs we have found. And we made a good choice - now after half a year, Pollock is still beta...

Yes, I understand the motives for wanting to re-engineer the UI framework. However, in the meantime we still need to develop now. Unfortunately once time goes by, one has such a large investment in time (and knowledge gained) spent smoothing things in the base system that the thought of redoing it again is frightening. From what I gather, at the moment Pollock is a risky choice.

So wrapper it is. I for one have a big investment in it, (as I'm sure a

lot of other people do). Therefore Cincom should definitely not wait for

Pollock, and at the very least tune/maintain/fix what's already there.

Well, I don't know if it would be worth it - I am almost sure I would still need to 'tune' it...

I’d say it’s essential. You can’t just ignore (what I am assuming) is a large segment of Cincoms customer base. Without doing a complete rewrite, (and not even a major refactoring), I feel that the initial developer experience of Wrapper could be seriously improved by attending to a few “little things” as discussed.

This would give VisualWorks a slicker “look and feel”, and free up developer time to concentrate on their project at hand, rather than addressing these irritating base image blemishes.

My two cents…

Cheers,

Stewart

Ladislav Lenart

</rant mode>

-----Original Message-----

From: Reinout Heeck [[hidden email]]

Sent: 24 March 2006 7:58

To: VW NC

Subject: Re: Multi-process windows manager

I find the WM implementation to be immature (unstable),

unfortunately

Cincom's position seems to be that Pollock will fix it all, and

we'll

have to work with what we have till then.

[...]

What I

find hard to accept is your explanation of Cincom's position. For big

applications Pollock is not a cost free "just switch it on" option. I

am

not desperate for Pollock at all - it is very likely that I will not

see

any it in our system before good number of months have gone by. In

such

case it tastes a bit bitter to simply sit there and wait for

Pollock...

I see I phrased that misleadingly, it is not so much that Pollock

itself

will fix it but that Cincom's priorities are to focus resources on

developing Pollock rather than fixing Wrapper. So I am guessing that

the

WM will regain Cincom's attention after Pollock is production ready.

But

I am obviously not authoritative on that. Note that developing the WM

is

one of those 'no fun' chores, you really need to think before hitting

accept or your image will freeze, the same goes for interaction with

other subsytems like flyby help.

Sam can we entice you to describe Cincom's planning regarding finishing

the WM?

I have not heard much of pro-multi WM arguments here. Is anybody

actually really benefiting from it?

Yes, developers benefit big time. I find it great that my browsers and

workspaces keep working while I'm debugging a UI thread (as opposed to

/the/ UI thread as it was in pre-WM days), a real productivity boon.

--

Reinout Heeck

-------------

Idle curiosity is the enemy of a quiet life.