Re: A plea for some fore thought.... (was Re: calendar questions)

[jg pa dec com (Jim Gettys)]

> From: Havoc Pennington <rhp@zirx.pair.com>
> Date: Tue, 23 Mar 1999 22:46:38 -0500 (EST)
> To: Jim Gettys <jg@pa.dec.com>
> Cc: gnome-list@gnome.org
> Subject: Re: A plea for some fore thought.... (was Re: calendar questions)
> -----
> On Tue, 23 Mar 1999, Jim Gettys wrote:
> >
> > I second the complaint...  Or rather, this is a polite request for people
> > to start thinking about how things can be made to work on small displays;
> > in particular, I'm thinking along the lines of PDA displays...
> >
> 
> Jim, you should know the answer to this question: how does one even find
> out how big the display is? Does X provide a way?

Yes.  There is an X library interface that provides it; it is available
as soon as the connection and library is "live"; the size of each screen
is contained in the information sent back when the initial protocol handshake
occurs.  Look at XWidthOfScreen() and XDisplayWidth and related information.

Note that X also provides the actual size of the screen, not just the
# of pixels; you might choose different strategies depending on physical
size of the screen vs. # of visible pixels.

You might buy a copy of Bob's and my book... :-).  Or read the source...

> 
> Unfortunately the hooks we would need in Gtk to adapt to screen size
> aren't there I don't think. Probably Gtk should pick its default font size
> based on screen size, allowing gtkrc to override; but the real problem is
> that there's no way to know how large one's app window is going to be. If
> you did know, you could gtk_window_set_default_size() in the case where it
> was too large. Alternatively, a gtk_window_max_size() could be added which
> automatically clamped the default size to some maximum. Other than that,
> there's little to do; add scrollbars perhaps, reduce padding between
> widgets a little...

By convention, X applications are supposed to take -geometry arguments
on startup, which can provide the size (these are window manager hints
in the ICCCM).

This size can also be set in Xt applications by setting the appropriate
resource.  This is also good, in my humble opinion.

Gtk should obey this convention.  It isn't rocket science, and has
been present in X applications since almost the beginning.

> 
> > Time to start rethinking GUI work; nice as Gnome is, I'd also like
> > some of the applications, at least, to be usable on such devices. I'm
> 
> For PalmPilot-size computing I think it actually makes little sense to use
> a smaller version of Gnome. PalmPilot applications are very different from
> the usual windows/mouse applications and that's why people like the
> device. However the "very small laptop" category could benefit.

I want Gnome applications, more than gnome over all; I expect the moral
equivalent of the panel to be quite different on a small screen device.
(might be wrong; some of the applets are small enough to be quite usable
on small screen displays; the size of the images would likely
at leat have to shrink...).

Note that Itsy has a higher resolution screen than the Palms have had
(dunno about the latest Palm 5).

> 
> For the PalmPilot sort of devices, I would say the correct route is to
> emphasize portability and toolkit independence in the application code.
> A nice example is AbiWord - they have 90% shared code across Gtk and
> Windows. So assuming you want a word processor on a PalmPilot,
> it's only a 10% job to write a new frontend. Actually more like 5% I'd
> guess - the "hard parts" and design work are in the backend.

That doesn't get me alot of applications without messing with them.  It
is clear that some applications will need significant rework; it is also
clear that many applications shouldn't need much more than tuning font
size and a bit of thought that it might run on a small display.  Some
shouldn't need any work at all (e.g. the applets in the gnome panel I'd
expect to work as is, though a further shrink might or might not be
productive.  I don't yet have an Itsy to play with to have an opinion.

> 
> For GnomeCal for example, all the file-format code, networking code,
> time-computation code, and data structure code could be shared. However
> you'd want to do the screen display differently or it would suck big time
> on one of those little handhelds... vice versa is true as well, I don't
> want some cramped touchpad interface on my 21-inch monitor.
> 
> This is the right way to write nontrivial applications anyway, since
> toolkits change and people change their mind about how they want the UI to
> work.
> 
I agree, but I note that a toolkit that does more of this for you will
be popular...
			- Jim