Re: RFC: new features

On Thu, Jan 12, 2012 at 1:38 PM, Christian Hergert <chris dronelabs com> wrote:
> On Thu, 2012-01-12 at 03:59 +0100, Benjamin Otte wrote:
>> 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.
> 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.
> 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.
> 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).
> 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.
> We already have entry completion, but it would be much more useful if it
> let you see the list of possible completions.

I'm not 100% sure, but I think this can be done now, if not it's really not
so far off the mark.

Generally you would create a gtk_combo_box_new_with_entry()
and add a GtkEntryCompletion to it.

We might be missing the part that, the dropdown menu should be
positioned completely *below* the combo box and the items should
be filtered while the user types, but I haven't tried it recently, it wouldn't
surprise me if we already support this feature.

> Cheers,
> [1]
> [2]
> [3]
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]