RE: GTK+-2.x planning

["David L. Cooper II" <cooperdl worldnet att net>]

I agree that we need to consider adding some stop gap support for printing.

I believe this effort should also include a standard printer selection
dialog (and maybe a separate page layout dialog). Or is that stating the
obvious?

Regards,

David

> -----Original Message-----
> From: gtk-devel-list-admin gnome org
> [mailto:gtk-devel-list-admin gnome org]On Behalf Of Havoc Pennington
> Sent: Tuesday, March 12, 2002 5:44 PM
> To: Owen Taylor
> Cc: gtk-devel-list gnome org
> Subject: Re: GTK+-2.x planning
>
>
>
> Owen Taylor <otaylor redhat com> writes:
> >  * What's missing? What do we need to do, that we _can_ do in
> >    2.x that isn't below? Feel free to be blue-sky, but blue
> >    sky stuff is at least 2.6, maybe 2.8 :-)
> >
>
> One thing I've been meaning to bring up is printing. Right now we
> basically have that on the someday-maybe 3.x timescale - which is 2004
> or most likely later. I think a stopgap would be valuable if we can
> come up with something meaningful, perhaps just a virtual
> GdkDrawable. But I don't know what the range of options would really
> be, what would be involved, or who we have who could work on it.
>
> Anyhow I think we should consider whether there's a stopgap that can
> be done with maybe a month of effort that wouldn't clutter the API too
> badly long term.
>
> Or perhaps a below-the-GTK-level solution is more appropriate. I'd
> like to see that too.
>
> > GTK+-2.2:
> >
> > * Multihead support
> > * Official Win32 port
> > * Fully usable RTL editing  (#73307, #70451, #50770)
> > * Xft2 support for Pango
> > * OpenType Indic shapers for Pango
>
> One more suggestion here is the "trivial shaper" people can use to
> implement terminals, fixed-cell-width text widgets, and cross-platform
> wrapper toolkits like SWT/AWT that want to see an X-style font API.
>
> i.e. essentially just "give me a glyph for each character in a string"
> - so people using Pango as an X core vs. Xft abstraction more or less.
>
> I'm not sure how complex a solution we need but maybe it can be done
> very simply and if so it might be a nice 2.2 candidate. The "use Xlib"
> suggestion is working really badly in practice since it means you lose
> the Xlib/Xft abstraction, and have to do your own font selector, and
> get different fonts in different places.
>
> > GTK+-2.4:
> >
> > * File selection widget
> > * Replacement combo/option-menu widget
> > * Action based menu API
> > * New toolbar widget (#70606, #6112, #50367, #55393)
>
> I would suggest doing the dock widget as well, in conjunction with the
> toolbar/menu stuff.
>
> > GTK+-2.6:
> >
> > * Icon list widget
>
> We may need a simple icon list for the file selector. We would to
> implement the usual Windows-like selector. It could be left private in
> 2.4 of course, if we did something so simple that it was useless
> outside of the filesel context.
>
> > * Sheet widget
>
> I consider this one sort of low priority.
>
> > * Reworked tooltips (#50619, #56291, #62174, #65490)
>
> Including more general help support, probably.
>
> > * Autocompletion and history for GtkEntry (#69613)
>
> This one is fairly high priority since it's needed to kill GtkCombo
> off.
>
> > * Disclosure triangle widget
> > * GnomeColorPicker style color selection button
>
> These two are so trivial they could really go in at any time, I don't
> see any value to delaying them past "whenever people put them together"
>
> I would add the font picker button and the file picker entry, in
> addition to the color picker.
>
> It looks to me like you sort of have the hard stuff (combo, filesel,
> menu API) all on 2.4, and a bunch of trivial stuff on 2.6;
> realistically at least one hard thing should probably be on 2.6.
>
> In my head I'd sort of thought about it in reverse, that for 2.4 we
> could just fill in a bunch of these little trivialities and then work
> on the hard stuff starting now but targeting 2.6.
>
> No doubt in practice we can just ship 2.4 in fall with whatever's
> ready by then, so we'll end up with whatever people decide to work on.
>
> Havoc
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list