Re: Call for text size and style advice for Gnome 2

[Havoc Pennington <hp redhat com>]

Darin Adler <darin bentspoon com> writes: 
> OK. My only quibble is that I have no idea how I can tell a legitimate need
> to set the size larger from a "random size". I agree that it's less likely
> to go awry in many ways if everything is as standard as possible.

All I mean by consistent sizes is that we should try to e.g. use the
PANGO_SCALE sizes probably, and tweak the value of PANGO_SCALE_LARGE
etc., instead of making up scale factors. Right now PANGO_SCALE_*
follows the CSS scale factors, just because that was better than
making up numbers, but I don't think there's any religious reason we
have to leave them at the CSS values if we really think there are
better ones.

One reason not to use the PANGO_SCALE_* values is that they may be
larger steps than Nautilus really wants, though, and something called
PANGO_SCALE_XX_LARGE maybe shouldn't just result in adding a few
points to the font. In that case maybe we shouldn't use them in
Nautilus. I don't know.

> So to summarize: To apply a PangoAttrScale I need to use widget-specific
> code. But I can easily modify the font in a widget-independent way. But
> that's not good because it ends up requesting a specific font rather a size
> relative to the default.

Yeah. Not the best thing ever - I wanted gtk_widget_scale_font() or
something, but we didn't figure out how to do that in time I guess.

Nearly all text-displaying widgets do support AttrList somehow though.

It's probably also fine to use gtk_widget_modify_font() as long as we
handle style_set etc., which I guess Nautilus always has. Trivial to
apply a scale factor ourselves in the style_set handler. Maybe this is
what make_larger should do.
 
> Sounds fine. In the cases I'm talking about, we always want the attribute on
> the entire string. Do you happen to knowof an example of code that sets a
> PangoAttrList on a label that I can look at? I'm pretty ignorant about
> properties and such, and these non-type-checked interfaces typically lead to
> me doing lots of trial and error coding.

You can also use gtk_label_set_attributes() to avoid the properties
goo.

I can't think of a good AttrList example offhand, but roughly the way
it works is that you call pango_attr_scale_new(), set start_index and
end_index in the AttrScale, then insert the attr scale into the
AttrList with pango_attr_list_insert(), then
gtk_label_set_attributes(). start_index should be 0 and end_index
G_MAXINT in this case I think.
 
> > Anders says it crashes, I can look at fixing it, I just keep
> > forgetting. In any case, it was one theory on how to rewrite the
> > ellipsization.
> 
> Great! It's good that we at least have a start. At the moment, though, eel
> doesn't even have a placeholder for this, so we can't insert the calls in
> the appropriate places.

I think the patch is basically right, just buggy. I never actually
tried running the code, and I'm not really one of those people that
types in a couple hundred complicated lines and it just works the
first time. ;-)
 
> I am aware of this issue. I predict that it will be easy to find all the
> places that need to be fixed. There's probably mainly one place we have to
> validate the file names, the function nautilus_file_get_display_name. There
> might be a few other places, but not a lot. But I don't know what to do when
> g_utf8_validate returns false. Ideas?

Hard to say. One option is to remove all the invalid pieces from the
file name, which makes sense if there's one weird character, but I
don't know what you do if all that's left after stripping invalid
stuff is "" or "q".  I guess you could display "<corrupt file name>"
or even put up some kind of dialog...

> (I also don't know whether there might be some circumstances where I want to
> do a character set conversion rather than just a validate. The presence of
> g_filename_to_utf8 in glib definitely creates some doubt in my mind, but I
> do remember Owen saying that for Unix the most sane solution he could think
> of was simply decreeing that filenames are UTF-8 and getting legacy file
> names wrong.)

filename_to_utf8 is just a strdup() by default, but if you set
G_BROKEN_FILENAMES it will convert from the locale encoding. ;-) Kind
of lame. Anyway, Nautilus should probably use it, so people can use
G_BROKEN_FILENAMES.

I can also imagine issues with remote filesystems, say SMB, probably
SMB has some defined filename encoding, and gnome-vfs would have the
smarts on what to do with it...

Havoc