gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz] Background


From: Matti Katila
Subject: [Gzz] Background
Date: Tue, 3 Sep 2002 00:16:17 +0300 (EEST)

BackgroundVob.peg
Matti Katila
2002-09-02T10:15:25

     

         -------                   ------------
      -------- |                   |          |
   --------- |--                ------------  |
   | Views |--                  | Windows  |---
   ---------                    |          |
                                ------------
        \            . . .. ..      /
         \        ---------- :     /
          \    ----------- |.:    /
           \__ | BGVobs  | |  ___/
               |         |--
               -----------





Last week I introduced myself to the problem of background vob.

Nowadays the background is mostly made in FallbackClient.java:
   windows[0] = new Win(new LightColorScheme(0.233f));
   windows[1] = new Win(new LightColorScheme(0.555f));

..and the background color is saved in FallbackClient.Win:
   Color col, bg;

This leads to some problems:
   -A view can't have an image on background
   -It isn't easy to change the color of a specified view because the 
    color isn't an attribute of the view.


I tested this on friday:
  http://people.jyu.fi/~majukati/patch/BGVob.java
where the basic concepts were like this:
   Fallback saves: color
   View     saves: nothing
   BGVob    saves: ratio of color for view    

This wouldn't break the current architecture much but in general 
I don't like it and it's also ugly. 

I refer to irc conversation [2002-08-29T12:11/46] at #gzz
with Tuomas. Tuomas ended up to summarize that a view should know 
what it views. So I decided to write this peg although Tuomas said
we should not save too much information about things into objects
but in zz-structure. I think if view has a background color/image it
should absolutely know it.

Well, I started by writing down a simple abstract class for every
concrete view. It has public settings available(somehow I just
like this way. How about you?).


class abstract AbstractView {

    public Settings settings

    public class Settings {
        private Color bg_color[];
        protected boolean hasBGImage = false;
 
        public Settings(int win_count) {
            bg_color = new Color[win_count];
        }

        private boolean badIndex(int index) {
            if ( 0 >= index && index <bg_color.length) return false;
            return true;
        }

        public void setBGColor(int win_index, Color new_color) {
            if(badIndex(win_index)) return;

            bg_color[win_index] = new_color; 
        }

        public Color getBGColor(int win_index) { 
            if(badIndex(win_index)) return new Color(Color.white);

            return bg_color[win_index];
        }
 
        public void setImage(...) { ; }
    }

    public View(int win_count) { settings = new Settings(win_count); }
}


...and so on.

Then I wondered if this is a good way after all -- View.java
is basically simple but it has only few instances around. So could we just
expand View.java to the abstract class above?


 * Summa summarum *

-   windows[0] = new Win(new LightColorScheme(0.233f));
-   windows[1] = new Win(new LightColorScheme(0.555f));
+   windows[0] = new Win(0);
+   windows[1] = new Win(1);

-        Win(ColorScheme colors) ...
+        Win(int win_index) ...


BGVob is constructed with win_index and current view.
BGVob talks to View to get the background properties right.

At the end of VobScene the BGVob simply makes a good background and
that's it.


   -Matti





reply via email to

[Prev in Thread] Current Thread [Next in Thread]