[Top][All Lists]

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

Re: [GITGRUB] New menu interface (implementation)

From: Michal Suchanek
Subject: Re: [GITGRUB] New menu interface (implementation)
Date: Sun, 27 Sep 2009 18:12:01 +0200


2009/9/25 Bean <address@hidden>:
> Hi,
> Update:
> Some adjustment to data representation. For example:
> background = "/splash.png"
> means loads splash.png, no extra handling if loading fails (text mode
> or file not found)
> background = "/splash.png,,blue"
> means loads splash.png, if it fails, replace it with rect that has
> blue background

This sounds reasonable for a background image. The background can be
also used for transparent parts of the image. For a label icon the
background should be probably taken from the label, including
transparent background or image background. If the icon fails to load
the size is zero unless explicitly scaled.

> Add new number format to specify size for both graphic and text mode:
> space = 10/0

I would prefer if the spacing would not need to be specified
separately for text mode and graphics mode.

I hope I can get to creating some layout mockups so that we can see if
that is feasible.

> 10 pixel in graphic text, 0 in text mode
> New layout manger, it support the following parameters:
> columns
> valign
> halign
> width
> height
> vspace
> hspace
> vmargin
> hmargin
> width/height is the size of widget, if it's not set, the size is
> calculated automatically using the size of child widgets

For sizing two modes are useful: the minimum sizing that assigns the
size required to display all content and the maximum sizing that
expands the widget as much as possible. If width = 100% means that any
siblings are not displayed because the widget occupies exactly the
available space then a different notation would be useful for taking a
share of the available width.

> vmargin, hmargin is the distance between horizontal and vertical
> border, positive value is from left/top, while negative value is from
> right/bottom, for example:
> panel
> {
>  vmargin = -0
>  hmargin = -0
> }
> places the panel in the bottom right corner.

How does this resolve the problem of setting the top, left, bottom and
right margin without knowing the size (width, height) of the panel?

I know that when panel is drawn the size is known but the size might
not be known when the configuration is written (different screen sizes
or label lengths). Setting the size (width, height) might be
appropriate in some cases but in most it should be calculated
automatically so that the layout fits in the available space.

I might want a bit of space (like 0.5 em or 0.5c) around a label so
that the label text is not sticking to the border as it was in the
last demo.

If I have a background picture over which I want to draw the menu and
it has a designated area for this I can either measure the menu
position as x,y,width, height or as top, left, bottom, right. The
latter has the advantage that if I decide to allow scaling the picture
I can measure the margin in % and the rounding error for each border
is the same. For x,y,width,height the rounding error of the bottom
corner is twice as large.

In the general case I would want to avoid the menu sticking to the
border of the screen which again calls for a margin.

> Here is a sample config file that shows different valign/halign
> combination, the image file is inside the previous
> screen
> {
>  halign = "center"
>  valign = "center"
>  columns = 3

This is not nice because when you add a new panel it wraps to the next
row. For most uses grouping panels in a single direction seems more
useful. When they have some logical order that order is preserved when
a new panel is added.

>  background = "/menu/back.png"
>  panel
>  {
>    background = ",blue"
>    hspace = 10/0
>    vspace = 5/0
>    halign = left
>    valign = top
>    width = 28%
>    height = 28%

Calculating this value is error prone and redundant since it is the
same for all panels.



reply via email to

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