[BUG] Motif look problems

Christian,

>Anyhow, I tried to prevent this by switching the look to Auto Select (which
>is Windows XP on my machine (WinXP sp2)). The Pollock window then works
>fine, but I still had the Browser (and the launcher and the app window) open
>in the Motif look. As soon as I clicked on a package in the browser, an
>endless loop started which is trying to find the background color of a
>button (see attached stack copy endlessLoop.txt).

This is an interesting problem I've been working on.

The issue isn't the size of the pixmap, but rather that upon startup, the masks
have dead handles. So, I'm thinking I need to do a check on the masks whenever I
try to use 'em, and if they're bad, remake them.

The other problem, well, that is a known general (Wrapper too) problem we
thought we had kicked.... apparently not.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

I'm wanting to implement a VisualSmalltalk-like GraphPane under Pollock.  Is
the Form class the right object to base this on?  If so, what would be the
simplest code snippet to demonstrate drawing something in a Form and then be
able to use scrollbars on it?

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com

Carl,

>I'm wanting to implement a VisualSmalltalk-like GraphPane under Pollock.  Is
>the Form class the right object to base this on?  If so, what would be the
>simplest code snippet to demonstrate drawing something in a Form and then be
>able to use scrollbars on it?

Probably not Form. Form is a container, and you are really just writing on the
pane, not adding sub-panes.

I'd say subclass from AbstractPane. That's easy for the drawing, but not for the
Scrollbars. Region does drawing, but not Scrollbars.

Sometime this summer a new pane will be coming out. It'll be named something
like OwnerDraw. It itself won't do any drawing, but instead will call a block
you supply (or a method selector), which will pass a GraphicsContext and the
pane itself, and allow you to draw to your hearts content. However, this pane
will not support Scrollbars.

Scrollbars are not first class panes in Pollock, and there isn't any plan to
make them so.

Finally, dealing with Scrollbars can be a huge pane... eh... pain. In terms of
coordinating them with the artist and agent. Not for the faint of heart.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

> Carl,
>
> >I'm wanting to implement a VisualSmalltalk-like GraphPane under Pollock.
Is
> >the Form class the right object to base this on?  If so, what would be
the
> >simplest code snippet to demonstrate drawing something in a Form and then
be
> >able to use scrollbars on it?
>
> Probably not Form. Form is a container, and you are really just writing on
the
> pane, not adding sub-panes.
>
> I'd say subclass from AbstractPane. That's easy for the drawing, but not
for the
> Scrollbars. Region does drawing, but not Scrollbars.

So should I put my AbstractPane into a Form and use its scrollbars somehow?

> Sometime this summer a new pane will be coming out. It'll be named
something
> like OwnerDraw. It itself won't do any drawing, but instead will call a
block
> you supply (or a method selector), which will pass a GraphicsContext and
the
> pane itself, and allow you to draw to your hearts content. However, this
pane
> will not support Scrollbars.

Why isn't there a plan to create a scrollable drawing control?  A lot of
applications need this sort of thing.

> Scrollbars are not first class panes in Pollock, and there isn't any plan
to
> make them so.
>
> Finally, dealing with Scrollbars can be a huge pane... eh... pain. In
terms of
> coordinating them with the artist and agent.

No simple event driven interface?

>Not for the faint of heart.

Well, I wasn't looking to be told how hard this is going to be.  Quite the
contrary.  I was hoping for concrete direction about what to do.

I'm quite surprised to be told that this is hard to do.  Why should it be?

Is there any documentation in the works that explains how to create one's
own Pane+Agent+Artist?

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com

Sam,

> Finally, dealing with Scrollbars can be a huge pane... eh... pain. In
terms of
> coordinating them with the artist and agent. Not for the faint of heart.

I'm not fainthearted.  If you can give me some pointers I'd be glad to try
and make this work.  Once I get it working I'll gladly make it a publicly
available goodie.

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com

Carl,

>Why isn't there a plan to create a scrollable drawing control?  A lot of
>applications need this sort of thing.

Really? First I heard of it. Not being coy, just haven't.

>> Scrollbars are not first class panes in Pollock, and there isn't any plan to
>> make them so.
>>
>> Finally, dealing with Scrollbars can be a huge pane... eh... pain. In terms of
>> coordinating them with the artist and agent.
>
>No simple event driven interface?

Nope.

>>Not for the faint of heart.
>
>Well, I wasn't looking to be told how hard this is going to be.  Quite the
>contrary.  I was hoping for concrete direction about what to do.

Well, that's usually out of scope of my messages here.

>I'm quite surprised to be told that this is hard to do.  Why should it be?

Well, lot's of things are hard to do. A Microsoft like IconList is hard to do.

>Is there any documentation in the works that explains how to create one's
>own Pane+Agent+Artist?

Actually, yes, on my blog. But it doesn't cover doing one with Scrollbars.

Here's the deal. Pollock actually does have a sub-framework that deals with
Scrollbars. It is part of the "interior decoration" sub-framework.

There are three basic kinds of interior decorations. Plain (without scrollbars),
simple scrolling (with scrollbars) and "Grid"

When you create your Pane/Artist/Agent, you first start by saying that your pane
has an interior decoration, and setting up the general stuff for that (which
includes adding an interiorDecoration iVar to the Artist, as well as setting up
the standard methods for accessing and setting it... See Button and ButtonArtist
for anything named interiorDecoration...)

Then, you have to have some methods on various pieces of your Pane, Artist and
Agent. Documentation (yeah, it's there) is on the Package comment for
Pollock-Panes.

It describes what the various methods a ScrollbarBorderDecoration expects from
the pane/agent/artist. Examples of course are everywhere in the actual code.

However, it seems to me that an OwnerDraw pane may be only what you need! You
draw on it, give it an extent, and add it to a Form. The Form does the scrolling
for you.

OwnerDraw panes are only a couple of months away. They are required as part of
adding a TreeView as the first column of a Grid.

Hope that helps some.

See you next week.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

Sam,

> >Why isn't there a plan to create a scrollable drawing control?  A lot
of
> >applications need this sort of thing.
>
> Really? First I heard of it. Not being coy, just haven't.

Any application that needs to display things that need to be scrolled:

-images
-maps
-a plotted graph
-flowchart (HotDraw in Pollock?)
-a UML diagram (like the one in the VW browser)
-a drawing program
-any custom widget that needs to scroll
-and the like

> >> Scrollbars are not first class panes in Pollock, and there isn't
any plan to
> >> make them so.
> >>
> >> Finally, dealing with Scrollbars can be a huge pane... eh... pain.
In terms of
> >> coordinating them with the artist and agent.
> >
> >No simple event driven interface?
>
> Nope.
>
> >>Not for the faint of heart.
> >
> >Well, I wasn't looking to be told how hard this is going to be.
Quite the
> >contrary.  I was hoping for concrete direction about what to do.
>
> Well, that's usually out of scope of my messages here.

Why?  If you're the expert on Pollock, why shouldn't I be able to ask
you questions about how to use Pollock?

> >I'm quite surprised to be told that this is hard to do.  Why should
it be?
>
> Well, lot's of things are hard to do. A Microsoft like IconList is
hard to do.

I don't know about IconLists, but scrollbars are a standard part of any
UI framework and they should be easy to use.

> >Is there any documentation in the works that explains how to create
one's
> >own Pane+Agent+Artist?
>
> Actually, yes, on my blog. But it doesn't cover doing one with
Scrollbars.
>
> Here's the deal. Pollock actually does have a sub-framework that deals
with
> Scrollbars. It is part of the "interior decoration" sub-framework.

Ok.

> There are three basic kinds of interior decorations. Plain (without
scrollbars),
> simple scrolling (with scrollbars) and "Grid"
>
> When you create your Pane/Artist/Agent, you first start by saying that
your pane
> has an interior decoration, and setting up the general stuff for that
(which
> includes adding an interiorDecoration iVar to the Artist, as well as
setting up
> the standard methods for accessing and setting it... See Button and
ButtonArtist
> for anything named interiorDecoration...)
>
> Then, you have to have some methods on various pieces of your Pane,
Artist and
> Agent. Documentation (yeah, it's there) is on the Package comment for
> Pollock-Panes.
>
> It describes what the various methods a ScrollbarBorderDecoration
expects from
> the pane/agent/artist. Examples of course are everywhere in the actual
code.

I'll give all of that a good looking over.

> However, it seems to me that an OwnerDraw pane may be only what you
need! You
> draw on it, give it an extent, and add it to a Form. The Form does the
scrolling
> for you.
>
> OwnerDraw panes are only a couple of months away. They are required as
part of
> adding a TreeView as the first column of a Grid.

Great.  Do TreeViews scroll?  ;-)

> Hope that helps some.

Looks promising.  Thanks.

> See you next week.

Can't wait.

-Carl

Carl,

> Why?  If you're the expert on Pollock, why shouldn't I be able to ask
> you questions about how to use Pollock?

It's a matter of scope. How to build a widget that has scrollbars is  
not just a couple of minutes message. It's a huge topic.

To cover it completely is way beyond a simple message.

For instance, how to create your own widget, and all the issues  
involved for looks and feels and frames and so on, took days and days  
of work. That work was posted as a long series of weekly postings on  
the Pollock blog, over the course of several months. Each post took a  
day to write.

Obviously, that didn't cover all possibilities of how to create  
widgets with all kinds of features. Announcements and Attributes  
weren't covered in that. Writing about using them in an existing  
widget is one thing, writing code to add them to a custom widget is  
quite another.

Is it easier to create a widget from scratch without scrollbars than  
in Wrapper? Absolutely yes. Overall, adding scrollbar support is  
still easier than Wrapper, but it is one of those things, that by  
itself, is no easier than in Wrapper.

There's a lot to know about internal framework behavior and  
expectations when you are writing widgets. There's almost none you  
need to know when you're using them.... At least in Pollock

                                 And So It Goes
                                      Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

Sames,

As I recall, in Wrappers you can just create a View Holder on your
scrollbar-less view (like a chart or an image) and have the option to
enable/disable horizontal/vertical scrollbars. Sounds easy enough, no?

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Samuel S. Shuster [mailto:[hidden email]]
Sent: Friday, April 21, 2006 2:04 PM
To: Carl Gundel
Cc: [hidden email]
Subject: Re: [Pollock]Graphics window and Form?

Carl,

> Why?  If you're the expert on Pollock, why shouldn't I be able to ask
> you questions about how to use Pollock?

It's a matter of scope. How to build a widget that has scrollbars is  
not just a couple of minutes message. It's a huge topic.

To cover it completely is way beyond a simple message.

For instance, how to create your own widget, and all the issues  
involved for looks and feels and frames and so on, took days and days  
of work. That work was posted as a long series of weekly postings on  
the Pollock blog, over the course of several months. Each post took a  
day to write.

Obviously, that didn't cover all possibilities of how to create  
widgets with all kinds of features. Announcements and Attributes  
weren't covered in that. Writing about using them in an existing  
widget is one thing, writing code to add them to a custom widget is  
quite another.

Is it easier to create a widget from scratch without scrollbars than  
in Wrapper? Absolutely yes. Overall, adding scrollbar support is  
still easier than Wrapper, but it is one of those things, that by  
itself, is no easier than in Wrapper.

There's a lot to know about internal framework behavior and  
expectations when you are writing widgets. There's almost none you  
need to know when you're using them.... At least in Pollock

                                 And So It Goes
                                      Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

> From: [hidden email] [mailto:[hidden email]]
>
> Carl,
>
> >Why isn't there a plan to create a scrollable drawing control?  A lot
of
> >applications need this sort of thing.
>
> Really? First I heard of it. Not being coy, just haven't.

Wow, they must really keep you chained to that desk, Sames! Somebody set
him free to see just how many apps have a scrolling graphics pane :-)

In VW itself:
- GF/ST
- HotDraw
- Store's "Graph Versions"
- RB hierarchy pane
- Advance
- Business Graphics?

VW customers / apps:
- MetaEdit+
- Deutsche Bahn's routing & scheduling (seen on VW video)
- ElastoLab
- Condor Rebar Consultants
- ARTware
- ControlWORKS (Adventa)
- Kyma by Symbolic Sound
- KnowledgeScape
- Satellite Forces
- Steinmayer Net Intelligence

There are of course plenty more around, and some of these may no longer
be active - I just did a quick run through the whysmalltalk list, and
added some from memory.

Steve

Add BottomFeeder - the WithStyle pane (and, obviously, WithStyle itself)

At 05:12 PM 4/21/2006, you wrote:
<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView

Carl,

>-images
>-maps
>-a plotted graph
>-flowchart (HotDraw in Pollock?)
>-a UML diagram (like the one in the VW browser)
>-a drawing program
>-any custom widget that needs to scroll

It has occurred to me over the last two days that maybe you don't need a
GraphWidget: Only the last one may be have to be done by hand.

One can always do the following:

Create a pixmap, draw on that (according to the user's input, or an image or
whatever).

Make a DisplayImage with that pixmap. (via pixmap asImage if you want).

Put the DisplayImage in a Form. Poof, auto scrollbar behavior (with maybe having
to set the contentsExtent: method).

When the user changes the image, write to that pixmap, and put it again in the
same DisplayImage... Poof, auto update.

This works with ANY of the above, except a custom widget that needs to scroll.

Even then, I'm having a hard time figuring out why one would need a custom
widget. Even a Drawing Program and HotDraw and so on can all be done like
this... HotDraw only has to appear to display real circle objects and so on,
instead, they can be made to draw on the pixmap, and then update the
DisplayImage. They'll still be real objects under the hood, but the graphics
don't need to be real widgets.

UML Diagram, Plotted Graph... in the end they're all just things drawn on a
display surface... the Pixmap, and shoved directly onto the DisplayImage and
onto the screen.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

Boris,

>As I recall, in Wrappers you can just create a View Holder on your
>scrollbar-less view (like a chart or an image) and have the option to
>enable/disable horizontal/vertical scrollbars. Sounds easy enough, no?

No different than having a DisplayImage (which you write to via a pixmap) in a
Form which has scrollbars. More than easy.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

> It has occurred to me over the last two days that maybe you don't need
a
> GraphWidget: Only the last one may be have to be done by hand.
>
> One can always do the following:
>
> Create a pixmap, draw on that (according to the user's input, or an
image or
> whatever).
>
> Make a DisplayImage with that pixmap. (via pixmap asImage if you
want).
>
> Put the DisplayImage in a Form. Poof, auto scrollbar behavior (with
maybe having
> to set the contentsExtent: method).
>
> When the user changes the image, write to that pixmap, and put it
again in the
> same DisplayImage... Poof, auto update.

Sam,

Okay, this is actually pretty funny now.  :-)

If you look at my original post it says "I'm wanting to implement a
VisualSmalltalk-like GraphPane under Pollock."  I didn't say that I
needed you to build one for me.  I just wanted to be able to draw
graphics and have them scrollable.  Any support for 'objecty' VSE
GraphPane-like behavior I was happy to implement myself.

Let's sit down for a few minutes at the conference.  Based on what
you've said, I bet we can have the simplest working example in less than
half an hour.

Thanks,

-Carl

Samuel S. Shuster wrote:
> UML Diagram, Plotted Graph... in the end they're all just things drawn on a
> display surface... the Pixmap, and shoved directly onto the DisplayImage and
> onto the screen.
>  

What if the displayed objects are sensitive, i.e. real "views" with
controllers as in Wrapper? I've built editors that construct tree-like
composite structures of views, each of which has its own controller and
behavior (sometimes 100+ views in a single scrollable window). Actually
this editor is a large worksheet containing deeply structured
information which is directly editable.

Is that also possible with Pollock?

Andre

Andre,

> Is that also possible with Pollock?

Absolutely.

                                 And So It Goes
                                      Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

Andre Schnoor wrote: Sorry Andre forgot to reply all in the first attempt...

Amongst other things Michael Lucas-Smith will be demonstrating how you
can embed any number of existing "user interfaces" into a Pollock
window. He has an example that in just a few lines embeds a working Pong
game into a window containing styled text. The Pong game is playable and
its visual attributes are then controllable by CSS.

The Pong game itself knows nothing of CSS or the fact it has been
embedded into a new environment.

See Michael's presentation at Smalltalk Solutions.

cheers
Steve A