On 11 Aug 2008, at 14:04, Tommi Komulainen wrote:
On Thu, Aug 7, 2008 at 7:02 PM, Alexander Larsson <[EMAIL PROTECTED]>
wrote:
Is a physical size units even interesting? It just generally leads to
DPI style flamewars. For instance, a projector screen is really
large,
but you don't want ti
On Thu, Aug 7, 2008 at 7:02 PM, Alexander Larsson <[EMAIL PROTECTED]> wrote:
>
> Is a physical size units even interesting? It just generally leads to
> DPI style flamewars. For instance, a projector screen is really large,
> but you don't want tiny fonts anyway, because you watch it from far
> awa
Hi,
On Fri 08 Aug 2008 18:36, "BJörn Lindqvist" <[EMAIL PROTECTED]> writes:
> 2008/8/8 David Zeuthen <[EMAIL PROTECTED]>:
>> The thinking is that if the feature becomes default then the macro will
>> be resolved to a GtkSize with high bits set at compile time. For 2.x,
>> the thinking is that it
(resending, this time with the right address for the list)
On Fri, 2008-08-08 at 13:47 -0400, Behdad Esfahbod wrote:
> I suggest we do a function. Later on the function can be defined as a
> nop macro if needed (and a function version kept for ABI compat).
>
> So, gtk_size_em(1.0). Also define:
With C99 those functions could be inline (not fully aware of the C-version
status in gtk+), which would lessen the impact of it being a function but a
macro will undoubtedly always be faster.
2008/8/8 BJörn Lindqvist <[EMAIL PROTECTED]>
> 2008/8/8 David Zeuthen <[EMAIL PROTECTED]>:
> > The thinki
2008/8/8 David Zeuthen <[EMAIL PROTECTED]>:
> The thinking is that if the feature becomes default then the macro will
> be resolved to a GtkSize with high bits set at compile time. For 2.x,
> the thinking is that it will resolve to a function call and the
> conversion happens at run time, e.g.
In
On Fri, 2008-08-08 at 12:22 +0200, BJörn Lindqvist wrote:
> > A new macro GTK_UNIT_EM (and it's companion GTK_UNIT_ONE_TWELFTH_EM) is
> > introduced. This allows application to do e.g.
> >
> > hbox = gtk_hbox_new (FALSE, GDK_UNIT_EM (1));
> >
> > instead of
> >
> > hbox = gtk_hbox_new (FALSE, 12)
This patch is awesome stuff.
2008/8/6 David Zeuthen <[EMAIL PROTECTED]>:
> HOW IT WORKS
>
> A new macro GTK_UNIT_EM (and it's companion GTK_UNIT_ONE_TWELFTH_EM) is
> introduced. This allows application to do e.g.
>
> hbox = gtk_hbox_new (FALSE, GDK_UNIT_EM (1));
>
> instead of
>
> hbox = gtk_hbo
On Thu, 2008-08-07 at 20:02 +0200, Alexander Larsson wrote:
> Is a physical size units even interesting?
I guess I'll leave out GTK_SIZE_MM and GTK_SIZE_POINT for now. My main
point is ensuring that GtkSize is future proof in the sense that we can
add units later and preserve backwards compatibil
On Thu, 2008-08-07 at 20:02 +0200, Alexander Larsson wrote:
> Is a physical size units even interesting? It just generally leads to
> DPI style flamewars. For instance, a projector screen is really large,
> but you don't want tiny fonts anyway, because you watch it from far
> away. Something simila
On Thu, 2008-08-07 at 13:10 -0400, David Zeuthen wrote:
> Here's the revised proposal
>
> GTK_SIZE_EM
>GTK_SIZE_ONE_TWELFTH_EM for convenience
>
> GTK_SIZE_POINT
>cf. Behdad's proposal
>
> GTK_SIZE_MM
>GTK_SIZE_INCH for convenience
>
> GTK_SIZE_PIXEL
>
> The storage format is
On Thu, 2008-08-07 at 15:17 +0200, Alexander Larsson wrote:
> On Wed, 2008-08-06 at 17:07 -0400, David Zeuthen wrote:
>
> > Also, a new type GdkUnit (and it's unsigned companion GdkUUnit) is
> > introduced. It's typedef'ed to gint. Like jrb proposed some high bits
> > are cannibalized to tag that
On Wed, 2008-08-06 at 17:07 -0400, David Zeuthen wrote:
> Also, a new type GdkUnit (and it's unsigned companion GdkUUnit) is
> introduced. It's typedef'ed to gint. Like jrb proposed some high bits
> are cannibalized to tag that the given value is an em and not a pixel
> value. Also, some users of
On Thu, Aug 7, 2008 at 6:08 AM, Behdad Esfahbod <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-08-07 at 04:20 +0200, Soeren Sandmann wrote:
>> Behdad Esfahbod <[EMAIL PROTECTED]> writes:
>>
>> > Also, my only quick feedback is that you are hooking up on the font
>> > size, while you should instead hook
On Thu, Aug 7, 2008 at 3:08 AM, Behdad Esfahbod <[EMAIL PROTECTED]> wrote:
> I think what I mean is that most of the UI should use units in points,
> not in em's. That is, increasing font size should not necessarily
> increase all UI elements. I can't think of any concrete cases though.
>
I can,
On Wed, 2008-08-06 at 20:40 -0400, David Zeuthen wrote:
> I think in general you want the UI elements to scale along with how big
> the font appears on the screen; in other words, I think em is a more
> natural unit than point. But I'm no expert.
Different means of interaction (eg touch vs mouse)
Behdad Esfahbod <[EMAIL PROTECTED]> writes:
> > I'll repeat that making use of the physical size in the X Screen
> > structure is *BROKEN*. You don't want tiny fonts a projector, and you
> > don't want huge fonts on handheld.
> >
> > The number is meaningless without knowledge about the device ty
Hi again,
Just FYI, I've filed the patch here
http://bugzilla.gnome.org/show_bug.cgi?id=546711
so it doesn't get lost / is easier to review. Also, the API docs are now
complete [1]; see
http://people.freedesktop.org/~david/gtk-ri-patches/gdk/gdk-Units.html
for the unit API's and for example
On Thu, 2008-08-07 at 04:20 +0200, Soeren Sandmann wrote:
> Behdad Esfahbod <[EMAIL PROTECTED]> writes:
>
> > Also, my only quick feedback is that you are hooking up on the font
> > size, while you should instead hook on screen dpi. Think of screen dpi
> > as a global scaling factor, and font siz
Behdad Esfahbod <[EMAIL PROTECTED]> writes:
> Also, my only quick feedback is that you are hooking up on the font
> size, while you should instead hook on screen dpi. Think of screen dpi
> as a global scaling factor, and font size is relative size of the fonts
> to the other elements.
I'll repea
On Wed, 2008-08-06 at 20:46 -0400, Behdad Esfahbod wrote:
> > I think in general you want the UI elements to scale along with how big
> > the font appears on the screen; in other words, I think em is a more
> > natural unit than point. But I'm no expert.
>
> Sure, then hide the font size and only
On Wed, 2008-08-06 at 20:40 -0400, David Zeuthen wrote:
> On Wed, 2008-08-06 at 20:08 -0400, Behdad Esfahbod wrote:
> > I think what I mean is that most of the UI should use units in points,
> > not in em's. That is, increasing font size should not necessarily
> > increase all UI elements. I can'
On Wed, 2008-08-06 at 20:08 -0400, Behdad Esfahbod wrote:
> I think what I mean is that most of the UI should use units in points,
> not in em's. That is, increasing font size should not necessarily
> increase all UI elements. I can't think of any concrete cases though.
>
> If you just use dpi th
On Wed, 2008-08-06 at 19:42 -0400, David Zeuthen wrote:
>
> > Also, my only quick feedback is that you are hooking up on the font
> > size, while you should instead hook on screen dpi. Think of screen dpi
> > as a global scaling factor, and font size is relative size of the fonts
> > to the other
On Wed, 2008-08-06 at 17:43 -0400, Behdad Esfahbod wrote:
> Hi David!
>
> I'll write a detailed reply later, but this already looks fantastic.
Cool, thanks.
> I was also reading how Apple solved this problem. May be interesting:
>
> http://developer.apple.com/releasenotes/GraphicsImaging/RN-Re
David Zeuthen wrote:
PROPOSAL
My proposal is to merge something like this for gtk 2.x in the near
future and make it mandatory in gtk 3.0.
Flames, praises, thoughts?
Awesome!!! We could really use something like this in Sugar...
Marco
___
gtk-de
Hi David!
I'll write a detailed reply later, but this already looks fantastic.
I was also reading how Apple solved this problem. May be interesting:
http://developer.apple.com/releasenotes/GraphicsImaging/RN-ResolutionIndependentUI/index.html
Their three scaling modes may very well apply to us
Hi,
Btw, as the screen cast points out there are some issues with combo
boxes and the tree view using GdkPixbuf. It *think* this can be solved
by extending GdkPixbuf to optionally remember the "origin" and act
on ::unit-changed. But I haven't thought about it in detail.
(There's also a bug with G
On 6 Aug 2008, at 22:07, David Zeuthen wrote:
PROPOSAL
My proposal is to merge something like this for gtk 2.x in the near
future and make it mandatory in gtk 3.0.
Flames, praises, thoughts?
Initial impressions: sounds awesome. We've certainly always hated
having to give pixel spacings
Hey,
Many years ago jrb did a writeup about units
http://mail.gnome.org/archives/gtk-devel-list/2003-February/msg9.html
e.g. to make apps avoid using hard coded pixel values. The past few days
I've been working on implementing something similar to this in GTK+.
MOTIVATION
My main motivati
30 matches
Mail list logo
