Using DUIM's <viewport> 
Author Message
 Using DUIM's <viewport>

I'm writing a utility at work, and I wanted to create a NeXT-style
browser view.  For those who don't know, it will look like this:

+-----------------------------------------+
|   root         line 3                   |
| +----------+ +-------------+            |
| | line 1   | | sub-item 1  |            |
| | line 2   | | sub-item 2  |            |
| |#line#3###| |             |            |
| | line 4   | |             |            |
| | line 5   | |             |            |
| +----------+ +-------------+            |
|                                         |
|<::::::::::::::::##:::::::::::::::::::::>|
+-----------------------------------------+

I figured I'd use a <viewport> with a child <row-layout> and add
labelled <list-controls>.  But when I run the app, the area where the
viewport should show up is blank.

It's entirely possible that I am misusing that class.  It's not
well-documented.  Has anyone used this?  Any sample code?



Sat, 07 Sep 2002 03:00:00 GMT  
 Using DUIM's <viewport>
I don't quite understand what you are after, but I can explain a bit
more about this part of DUIM.  The <viewport> object really just
serves to provide a clipping region and a translation transform
that allows the underlying sheet to show through at the correct
position.  These get wrapped up in a "scroller", which lays out
the viewport, the scroll bars, and the scrolled child[ren].

I think where you should start is by wrapping the 'scrolling' macro
around the sheet(s) you want to scroll.  DUIM does the rest.

There is a hack in the DUIM demos that does various kinds of
scrolling.

If this isn't enough to get you further, please trying explaining
what you want a bit less tersely, and I'll have another go.

Quote:

>I'm writing a utility at work, and I wanted to create a NeXT-style
>browser view.  For those who don't know, it will look like this:

>+-----------------------------------------+
>|   root         line 3                   |
>| +----------+ +-------------+            |
>| | line 1   | | sub-item 1  |            |
>| | line 2   | | sub-item 2  |            |
>| |#line#3###| |             |            |
>| | line 4   | |             |            |
>| | line 5   | |             |            |
>| +----------+ +-------------+            |
>|                                         |
>|<::::::::::::::::##:::::::::::::::::::::>|
>+-----------------------------------------+

>I figured I'd use a <viewport> with a child <row-layout> and add
>labelled <list-controls>.  But when I run the app, the area where the
>viewport should show up is blank.

>It's entirely possible that I am misusing that class.  It's not
>well-documented.  Has anyone used this?  Any sample code?



Sun, 08 Sep 2002 03:00:00 GMT  
 Using DUIM's <viewport>

Quote:

> It's entirely possible that I am misusing that class.  It's not
> well-documented.  Has anyone used this?  Any sample code?

If I understand what you want correctly, and based on Scott's reply to
look at the Scroller macro, the following may do something like what
you want:

--------------------8<----------------
define frame <scroll-test-frame> (<simple-frame>)
  pane lists-pane (frame)
    horizontally( spacing: 5)
      make(<list-box>, items: #[1, 2, 3, 4, 5]);
    end;

  pane scrolling-pane (frame)
    scrolling(scroll-bars: #"horizontal")
      frame.lists-pane;
    end;

  pane add-button (frame)
    make(<push-button>,
         label: "Add",
         activate-callback: do-add-list);

  layout (frame)
    vertically()
      frame.scrolling-pane;
      frame.add-button;
    end;
end frame;

define method do-add-list(g)
  let list-pane = g.sheet-frame.lists-pane;
  let new-child = make(<list-box>,
                       items: #[2, 4, 6, 8, 10],
                       parent: list-pane);
  relayout-parent(list-pane);
  new-child.sheet-mapped? := #t;
end method do-add-list;
--------------------8<----------------

Pressing the Add button will add a new list box and you can use the
scroller to scroll across the pane holding the list boxes.

On the downside, the above code has some repaint issues with FD 2.0
beta 3 when scrolling if there is more than one list box. Forcing a
repaint (minimizing then maximizing for example) causes the artifacts
to go away and the application draws correctly. Try it and you'll see
what I mean.

The code from do-add-list is basically copied from the example
duim-gui-test-suite in dynamic-layouts.dylan. That example just about
uses everything in Dylan and is a good one to look through to find out
how to do things.

Chris.
--
http://www.double.co.nz/dylan



Sun, 08 Sep 2002 03:00:00 GMT  
 Using DUIM's <viewport>


[snip NeXT user interface question]
Is it me, or are there often posts (not particularly here) about the
trying to recreate the NeXT UI?

I have two NeXT computers and love the UI.  You may buy one from me, if
you wish, Dustin :)

<!personal oppinion>
<rant>
How come UI design, power, and features *still* haven't caught up to
what NeXT did more than 10 years ago?  My starfield background looks
realistic (note to Microsoft -- lose or change yours), and it runs
while I'm running shells, apps, and my compiler.

Ah!  Here I am, back at work, using my WinNT box.  *SIGH*
</rant>

Doug Auclair

p.s. GD port to NeXT, anyone?

Sent via Deja.com http://www.deja.com/
Before you buy.



Sun, 08 Sep 2002 03:00:00 GMT  
 Using DUIM's <viewport>

Quote:


> > It's entirely possible that I am misusing that class.  It's not
> > well-documented.  Has anyone used this?  Any sample code?

> If I understand what you want correctly, and based on Scott's reply to
> look at the Scroller macro, the following may do something like what
> you want:

> --------------------8<----------------
> define frame <scroll-test-frame> (<simple-frame>)
>   pane lists-pane (frame)
>     horizontally( spacing: 5)
>       make(<list-box>, items: #[1, 2, 3, 4, 5]);
>     end;

>   pane scrolling-pane (frame)
>     scrolling(scroll-bars: #"horizontal")
>       frame.lists-pane;
>     end;

>   pane add-button (frame)
>     make(<push-button>,
>          label: "Add",
>          activate-callback: do-add-list);

>   layout (frame)
>     vertically()
>       frame.scrolling-pane;
>       frame.add-button;
>     end;
> end frame;

> define method do-add-list(g)
>   let list-pane = g.sheet-frame.lists-pane;
>   let new-child = make(<list-box>,
>                        items: #[2, 4, 6, 8, 10],
>                        parent: list-pane);
>   relayout-parent(list-pane);
>   new-child.sheet-mapped? := #t;
> end method do-add-list;
> --------------------8<----------------

> Pressing the Add button will add a new list box and you can use the
> scroller to scroll across the pane holding the list boxes.

> On the downside, the above code has some repaint issues with FD 2.0
> beta 3 when scrolling if there is more than one list box. Forcing a
> repaint (minimizing then maximizing for example) causes the artifacts
> to go away and the application draws correctly. Try it and you'll see
> what I mean.

> The code from do-add-list is basically copied from the example
> duim-gui-test-suite in dynamic-layouts.dylan. That example just about
> uses everything in Dylan and is a good one to look through to find out
> how to do things.

> Chris.

This code is what I'm looking for -- thanks! -- except for that repaint
problem.  It looks like the border and selection of each list box is
getting repainted, but not the rest of the content.

Can you (or anyone) think of a way to automatically repaint this?  Maybe
hook into some event somewhere?

I tried overriding handle-event, but that didn't work...

define method handle-event (f :: <lists-pane>, e :: <event>) => ()
   next-method();
   queue-repaint (f, $everywhere);
end method;

Thanks in advance!



Sun, 08 Sep 2002 03:00:00 GMT  
 Using DUIM's <viewport>

Quote:

> Can you (or anyone) think of a way to automatically repaint this?
> Maybe hook into some event somewhere?

If you don't mind a bit of flicker when scrolling, adding the
following method will do the trick:

-----------------8<-----------------
define method note-viewport-position-changed(
    frame :: <scroll-test-frame>,
    sheet :: <sheet>, x, y) => ()
  next-method();

  let region = frame.lists-pane.sheet-region;
  with-sheet-medium (medium = sheet)
    clear-box*(medium, region)
  end;
  repaint-sheet(sheet, region);

  do-sheet-children(update-gadget, frame.lists-pane);  
end;
-----------------8<-----------------

The method note-viewport-position-changed gets called when the
scrolling area is scrolled. It is called by scroll-viewport-child. It
looks like the redraw problem is somewhere in scroll-viewport-child or
something it calls. The method above erases the list panes and then
forces them to update again after scroll-viewport-child is called.

It is specialised on the frame so you'll have to add this method for
each frame where you do this sort of thing.

Hope that helps,
Chris.
--
http://www.double.co.nz/dylan



Mon, 09 Sep 2002 03:00:00 GMT  
 Using DUIM's <viewport>

--


Quote:

>> Can you (or anyone) think of a way to automatically repaint this?
>> Maybe hook into some event somewhere?

>If you don't mind a bit of flicker when scrolling, adding the
>following method will do the trick:

Nice trick, Chris! A possibility that might work is to add a single drawing pane as the window to be scrolled, and to then add the list boxes to that.

Here's an approximate sketch, I haven't tried this (I'll try and post a real version when I'm at home, unless Chris beats me to it):

define pane <my-scroll-window> ()
  layout (frame)
    make(<column-layout>);
end pane <my-scroll-window>;

define frame <my-window> (<simple-frame>)
  ...
    scrolling ()
      make(<my-scroll-window>);
end frame <my-window>;

Then add the new list boxes to the <my-scroll-window> class.

As to the bug itself, as Chris says it is a bug in the <viewport> class that was introduced in 2.0. I was aware of it (it shows up in one of the scrolling tests in the DUIM test suite), but I didn't have time to look into it before the beta release. I would love to fix it, it is vitally important to be able to scroll gadgets in a window.

Hope this helps,

Andy

MailCity. Secure Email Anywhere, Anytime!
http://www.mailcity.lycos.com



Mon, 09 Sep 2002 03:00:00 GMT  
 Using DUIM's <viewport>

Quote:

>--



>>> Can you (or anyone) think of a way to automatically repaint this?
>>> Maybe hook into some event somewhere?

>>If you don't mind a bit of flicker when scrolling, adding the
>>following method will do the trick:

>Nice trick, Chris! A possibility that might work is to add a single drawing pane as the window to be scrolled, and to then add the list boxes to that.

>Here's an approximate sketch, I haven't tried this (I'll try and post a real version when I'm at home, unless Chris beats me to it):

OK, here's the real version (it turns out 'define pane' no longer uses <drawing-pane>, so I had to use a different solution):

define frame <scrolling-test> (<simple-frame>)
  pane %column (pane)
    make(<column-layout>,
         children: vector(make(<push-button>, label: "Hello"),
                          make(<list-box>, items: #(1, 2, 3)),
                          make(<list-box>, items: #(4, 5, 6))));
  layout (frame)
    scrolling ()
      make(<drawing-pane>,
           children: vector(frame.%column),
           foreground: #f)
    end;
end frame <scrolling-test>;

define method main () => ()
  start-frame(make(<scrolling-test>));
end method main;

The only problem with this solution is that the background of the scrolling area is now white instead of the default Windows color. I can't seem to find a way to ask a drawing pane to pick up the default color, if that is a problem for your application I'll try and find a way.

Just for the record, the bugs I'd like to see fixed are:

1. <viewport> does inappropriate bitblt'ing when scrolling collections of gadgets.

2. <drawing-pane> cannot pick up the correct default background color, because it is overriden with $white. Maybe we need another class (<gadget-pane>?) that uses the default gadget color, or maybe we need a way to override this behavior (:background $default-background, or something).

I hope this helps,

Andy

---------------------------
Andy Armstrong

MailCity. Secure Email Anywhere, Anytime!
http://www.mailcity.lycos.com



Mon, 09 Sep 2002 03:00:00 GMT  
 Using DUIM's <viewport>

Quote:

>--



>>> Can you (or anyone) think of a way to automatically repaint this?
>>> Maybe hook into some event somewhere?

>>If you don't mind a bit of flicker when scrolling, adding the
>>following method will do the trick:

>Nice trick, Chris! A possibility that might work is to add a single drawing pane as the window to be scrolled, and to then add the list boxes to that.

>Here's an approximate sketch, I haven't tried this (I'll try and post a real version when I'm at home, unless Chris beats me to it):

OK, here's the real version (it turns out 'define pane' no longer uses <drawing-pane>, so I had to use a different solution):

define frame <scrolling-test> (<simple-frame>)
  pane %column (pane)
    make(<column-layout>,
         children: vector(make(<push-button>, label:

MailCity. Secure Email Anywhere, Anytime!
http://www.mailcity.lycos.com



Mon, 09 Sep 2002 03:00:00 GMT  
 Using DUIM's <viewport>

Quote:


> > Can you (or anyone) think of a way to automatically repaint this?
> > Maybe hook into some event somewhere?

> If you don't mind a bit of flicker when scrolling, adding the
> following method will do the trick:

> -----------------8<-----------------
> define method note-viewport-position-changed(
>     frame :: <scroll-test-frame>,
>     sheet :: <sheet>, x, y) => ()
>   next-method();

>   let region = frame.lists-pane.sheet-region;
>   with-sheet-medium (medium = sheet)
>     clear-box*(medium, region)
>   end;
>   repaint-sheet(sheet, region);

>   do-sheet-children(update-gadget, frame.lists-pane);  
> end;
> -----------------8<-----------------

> The method note-viewport-position-changed gets called when the
> scrolling area is scrolled. It is called by scroll-viewport-child. It
> looks like the redraw problem is somewhere in scroll-viewport-child or
> something it calls. The method above erases the list panes and then
> forces them to update again after scroll-viewport-child is called.

> It is specialised on the frame so you'll have to add this method for
> each frame where you do this sort of thing.

> Hope that helps,
> Chris.

That seems to work fine (aside from the flicker) for list boxes.  I had
intended to use list controls, though, and this technique doesn't work
for that.  I poked around in the source code, but couldn't figure out
what was different.

Interestingly, if I do this (IIRC)...

define method note-position-changed (frame :: <frame>, sheet :: <sheet>)
  next-method();
  sheet.sheet-mapped? := #f;
  sheet.sheet-mapped? := #t;
end;

...it works correctly for list controls as well as list boxes.  But it
still flickers, and the control loses focus -- I tried to save and reset
the focus to no avail.

I dug through the DUIM source and tried to find why this works.  My best
guess is that relayout-parent or relayout-children is responsible, but I
called those functions manually and the controls didn't repaint properly.

I think I'll try to make my own control.  Wish me luck! -- I'm sure I'll
need it.

Thanks for everyone's help!



Mon, 09 Sep 2002 03:00:00 GMT  
 Using DUIM's <viewport>

Quote:
> OK, here's the real version [...snip...]

I just tried your solution and it works great!

Quote:
> The only problem with this solution is that the background of the
> scrolling area is now white instead of the default Windows color.

One way I found was to use get-default-background:

    scrolling ()
      make(<drawing-pane>,
           children: vector(frame.%column),
           background: get-default-background(frame.port, frame.%column),
           foreground: #f)
    end;

I'm not sure exactly what get-default-background does behind the
scenes but it makes the background the default gadget background in
this example.

Chris.
--
http://www.double.co.nz/dylan



Tue, 10 Sep 2002 03:00:00 GMT  
 Using DUIM's <viewport>

Quote:

> That seems to work fine (aside from the flicker) for list boxes.  I had
> intended to use list controls, though, and this technique doesn't work
> for that.  

I think you'll be pleased to know that Andy's solution works for list
controls (and the other gadgets as well).

Chris.
--
http://www.double.co.nz/dylan



Tue, 10 Sep 2002 03:00:00 GMT  
 Using DUIM's <viewport>

Quote:


> > OK, here's the real version [...snip...]

> I just tried your solution and it works great!

> > The only problem with this solution is that the background of the
> > scrolling area is now white instead of the default Windows color.

> One way I found was to use get-default-background:

>     scrolling ()
>       make(<drawing-pane>,
>            children: vector(frame.%column),
>            background: get-default-background(frame.port, frame.%column),
>            foreground: #f)
>     end;

> I'm not sure exactly what get-default-background does behind the
> scenes but it makes the background the default gadget background in
> this example.

> Chris.

Although the get-default-background doesn't work with <win32-port> from
HD, I'm going to use this technique with the white background.  I
haven't dug through the source, but do you know why this works, but not
"pane scrolling() vertically() yadda-yadda end end"?


Tue, 10 Sep 2002 03:00:00 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. ><><><><>Heeeeeeeeeeeeeeelp on INT 14!><><><><><>

2. <<<<<YOU MUST CHECK THIS OUT >>>>>>>>>> 2103

3. <><><> FLOODFILL <><><>

4. <tree-node> in DUIM

5. [Call for Participation: <<UML>>'99]

6. <<UML>>'99

7. >>>HELP, DECOMPILER<<<

8. <<<XXX Password>>>

9. >>>>>>>>>>>>>>>>>>>HEY!<<<<<<<<<<<<<<<<<<<<<<<

10. <<<XXX Password>>>

11. ??? <<<<<<<<<<<<<<<<<<<< RGB 4 MMX >>>>>>>>>>>>>>>>>>>>>>>?

12. <<<XXX Password>>>

 

 
Powered by phpBB® Forum Software