Re: RFC: new features

[Christian Hergert <chris dronelabs com>]

On Thu, 2012-01-12 at 03:59 +0100, Benjamin Otte wrote:

> PLOTS
> This is my personal pet peeve. I often have something I'd like to
> quickly plot in GTK, but it always ends up being more complicated then
> I thought, so I either stare at text or use Gnumeric to get my plots.
> And all the other applications (like virt-manager or
> gnome-system-monitor) that do plotting look rather crappy and their
> plots don't provide a lot of features (no zooms, no tooltips with
> actual values, no ability to expand or collapse certain parts).
> However, is a plotting widget a useful addition to GTK? If it works
> well, it would surely enable people to show lots of useful statistics
> that we'd all be thankful for - collecting them is not hard after all,
> but making their output useful is. I'm sure a lot of people would like
> bandwidth graphs in NetworkManager, page load performance graphs in
> Epiphany or an interactive bootchart. Even if it's "just" the
> developers using it to improve the rest of the world.
> That said, such a widget would need a simple interface - both in API
> and UI, and I'm not seeing anybody working on that. But I'd be very
> interested.

The part I found frustrating while working on scrolling[1] graphs was
coming up with a good model for storing data points. Especially when you
consider being able to graph different scales or modes of graphs. Say
heatmap, 2d plot, 3d plot, etc. Linear or logarithmic scales, etc. And
then also abstracting the look of the plot and the renderers.

Below is a list of things that come to mind. I'm kind of forcing it, not
particularly attached to the list below. I'm just trying to provide some
diversity.

VALIDATION
Many developers in the web world have become accustom to "validating"
the contents of forms before submitting them. While we would often argue
against allowing invalid input in the first place, that can often
confuse users. In this case, allowing the input and providing an
accurate reason why the input is invalid yields better results. I'm not
sure what a good API here would look like, but it needs to be flexible
enough to work with built-in and custom widgets.

DOCKABLE PANELS
There is an in-between that might be reachable instead of a full docking
library. The idea is more of "panels". It's like float-able tool palette
that can be joined together. GIMP has this, and it's pretty bad. Which
could be an argument against it. But you can see a good implementation
in OmniGraffle[2] for OS X.

MENU BUTTON
A GtkButton that shows a menu when clicked (and handles positioning,
etc). Some would just use a combobox, but I find them pretty different.
You'll find this sort of "menu button" in various VMware products on
Linux. (I know the fullscreen toolbar used to have it at least).

WIDGET STACK
Like a notebook with no tabs or decoration. You "push" and "pop" widgets
on and off the stack. This is the navigational structure often found on
iOS. The reason I think abstracting it might make sense is more about
animating between widgets once Gtk starts landing animation (post
clutter integration obviously). It would be great if this nicely
integrated with a "navigation bar" type widget. Here[3] is a video of
some crappy animation code I wrote to do this.

ENTRY COMPLETION
We already have entry completion, but it would be much more useful if it
let you see the list of possible completions.

Cheers,

[1] http://audidude.com/?p=470
[2]
http://westergaard.eu/wp-content/uploads/2010/11/OmniGraffle-Professional-001.png
[3] http://www.youtube.com/watch?v=lp6ceGP-6vU