Re: RFC: new features
On Wed, 2012-01-18 at 09:49 +0100, Sergio Villar Senin wrote: En 13/01/12 16:04, Bastien Nocera escribiu: On Thu, 2012-01-12 at 11:23 +0100, Alexander Larsson wrote: On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote: snip 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). Gnome-contacts has one of these (at least in Gnome 3.2). Its not hard to do but would be nice to have in a single place. Also, it needs some help from the theme to look good, like adwaita does here: http://git.gnome.org/browse/gnome-themes-standard/commit/?id=90c4f48cf7720fb9b31e8388843a5fa6b8f3f705 Totem has a menu button as well, look for popup_button in: http://git.gnome.org/browse/totem/tree/browser-plugin/totem-plugin-viewer.c Epyphany hackers have also recently added the super menu which is a similar concept. Would anyone like to propose an API for how this should be implemented in Gtk? My assumption is just that we need a menu property and a menu position func with default implementation. Anything else? -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Wed, 2012-01-18 at 09:47 +0100, Alexander Larsson wrote: On Mon, 2012-01-16 at 13:08 +, Bastien Nocera wrote: On Fri, 2012-01-13 at 17:34 -0800, Christian Hergert wrote: Hopefully this isn't getting old, but I'm sort of just throwing these out there as I think of them. snip BACKGROUND OPACITY It would be nice to have the ability to alter the opacity of a window without altering the opacity of GdkWindow'd widgets inside it. This is useful for utility windows that float over a primary window. Right now, you have to handle changes with the visual and/or screen and modify the background yourself. This breaks possible theming and is tedious. http://www.pixelmator.com/ is a good example of why this might be useful. Had that problem in the Wacom calibration screen. I wanted the elements to be opaque but on a translucent dark background. It wasn't possible without resorting to hacks (such as having 2 windows, one translucent with the black background, one with the opaque elements on a transparent background). Can't you just make the window an RGBA window with a semi-transparent color on the toplevel, but normal bg colors on the other widgets? That sounds about right. If I understand the problem correctly, you have to make sure the visual supports RGBA and then update the GdkRGBA on style changes. My argument was that it would be nice if this was done for us with a background-opacity property between 0.0 and 1.0. -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Wed, 2012-01-18 at 11:56 -0800, Christian Hergert wrote: On Wed, 2012-01-18 at 09:47 +0100, Alexander Larsson wrote: On Mon, 2012-01-16 at 13:08 +, Bastien Nocera wrote: On Fri, 2012-01-13 at 17:34 -0800, Christian Hergert wrote: Hopefully this isn't getting old, but I'm sort of just throwing these out there as I think of them. snip BACKGROUND OPACITY It would be nice to have the ability to alter the opacity of a window without altering the opacity of GdkWindow'd widgets inside it. This is useful for utility windows that float over a primary window. Right now, you have to handle changes with the visual and/or screen and modify the background yourself. This breaks possible theming and is tedious. http://www.pixelmator.com/ is a good example of why this might be useful. Had that problem in the Wacom calibration screen. I wanted the elements to be opaque but on a translucent dark background. It wasn't possible without resorting to hacks (such as having 2 windows, one translucent with the black background, one with the opaque elements on a transparent background). Can't you just make the window an RGBA window with a semi-transparent color on the toplevel, but normal bg colors on the other widgets? That sounds about right. If I understand the problem correctly, you have to make sure the visual supports RGBA and then update the GdkRGBA on style changes. My argument was that it would be nice if this was done for us with a background-opacity property between 0.0 and 1.0. Thats not really possible. The way this works is that it sets an X property that the compositor uses when painting the window pixbuf. The compositor doesn't know what areas are part of some subwindow or subwidget. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On 01/18/2012 08:53 PM, Christian Hergert wrote: On Wed, 2012-01-18 at 09:49 +0100, Sergio Villar Senin wrote: En 13/01/12 16:04, Bastien Nocera escribiu: On Thu, 2012-01-12 at 11:23 +0100, Alexander Larsson wrote: On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote: snip 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). Gnome-contacts has one of these (at least in Gnome 3.2). Its not hard to do but would be nice to have in a single place. Also, it needs some help from the theme to look good, like adwaita does here: http://git.gnome.org/browse/gnome-themes-standard/commit/?id=90c4f48cf7720fb9b31e8388843a5fa6b8f3f705 Totem has a menu button as well, look for popup_button in: http://git.gnome.org/browse/totem/tree/browser-plugin/totem-plugin-viewer.c Epyphany hackers have also recently added the super menu which is a similar concept. Would anyone like to propose an API for how this should be implemented in Gtk? My assumption is just that we need a menu property and a menu position func with default implementation. Anything else? Maybe better discuss this in the bug. One issue I had was to come up with a suitable icon. Stefan -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
[sorry for the resend, something ate my mail] On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote: 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. Another +1 for plots, in particular a scrolling plot widget. I maintain a bit of scientific software for University and they all use real-time scrolling line charts. The basic requirements are * good performance (Christians was the best performing of those I tried) * multiple traces * autoscale * independently (of incoming data) adjustable scrolling speed * introspectable / usable from python[1] 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). And this too (if you are describing the wrench menu on chrome for example). John [1] Access from python because they get used in association with numpy, which is used for the static plots. In the end I chose to maintain a fork of the old rtgraph pygtk package https://github.com/nzjrs/rtgraph ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Fri, 2012-01-13 at 17:34 -0800, Christian Hergert wrote: Hopefully this isn't getting old, but I'm sort of just throwing these out there as I think of them. snip BACKGROUND OPACITY It would be nice to have the ability to alter the opacity of a window without altering the opacity of GdkWindow'd widgets inside it. This is useful for utility windows that float over a primary window. Right now, you have to handle changes with the visual and/or screen and modify the background yourself. This breaks possible theming and is tedious. http://www.pixelmator.com/ is a good example of why this might be useful. Had that problem in the Wacom calibration screen. I wanted the elements to be opaque but on a translucent dark background. It wasn't possible without resorting to hacks (such as having 2 windows, one translucent with the black background, one with the opaque elements on a transparent background). Do you mind filing a bug about that? Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Fri, 2012-01-13 at 15:04 +, Bastien Nocera wrote: On Thu, 2012-01-12 at 11:23 +0100, Alexander Larsson wrote: On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote: snip 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). Gnome-contacts has one of these (at least in Gnome 3.2). Its not hard to do but would be nice to have in a single place. Also, it needs some help from the theme to look good, like adwaita does here: http://git.gnome.org/browse/gnome-themes-standard/commit/?id=90c4f48cf7720fb9b31e8388843a5fa6b8f3f705 Totem has a menu button as well, look for popup_button in: http://git.gnome.org/browse/totem/tree/browser-plugin/totem-plugin-viewer.c Hacky. Filed https://bugzilla.gnome.org/show_bug.cgi?id=668013 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Mon, 2012-01-16 at 13:08 +, Bastien Nocera wrote: On Fri, 2012-01-13 at 17:34 -0800, Christian Hergert wrote: Hopefully this isn't getting old, but I'm sort of just throwing these out there as I think of them. snip BACKGROUND OPACITY It would be nice to have the ability to alter the opacity of a window without altering the opacity of GdkWindow'd widgets inside it. This is useful for utility windows that float over a primary window. Right now, you have to handle changes with the visual and/or screen and modify the background yourself. This breaks possible theming and is tedious. http://www.pixelmator.com/ is a good example of why this might be useful. Had that problem in the Wacom calibration screen. I wanted the elements to be opaque but on a translucent dark background. It wasn't possible without resorting to hacks (such as having 2 windows, one translucent with the black background, one with the opaque elements on a transparent background). Do you mind filing a bug about that? Filed as https://bugzilla.gnome.org/show_bug.cgi?id=668063 -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On 01/14/2012 10:26 AM, Stefan Sauer wrote: I agree that showing the tips as a startup dialog is somewhat annoying. On the other hand it would be useful to have a way to tell users about neat tricks and stuff and is not totally obvious. Sure, all of this can be documented in the manual, but apparently those are read even less often. Not sure if info bars that auto-hide after a while are better ... As for manuals and help files go, I'm not sure what is cause and what is effect. And of course there is something to be said for making features of programs easily accessible. I conceded that some use this tips feature, as another poster indicated. It might be worth gathering real use statistics on it if I were an app developer. Currently I can't think of any big-name, and well-used programs like Photoshop or MS Office that do this anymore, though they were very common a few years back. Seemed to me like it was a passing fad and Linux apps were late to the party! Not sure about info bars either, but they might be less intrusive and maybe people would actually read them. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On 13 January 2012 22:21, Paul Davis p...@linuxaudiosystems.com wrote: there is a bigger issue there, i think. in an ideal world, you don't want to base the date store for the TreeView on an object, but on an interface. then you want a series of adapters/wrappers that wrap data structures implemented in any language (or any language with a GTK binding) with the required interface. some of which might be null adapters that just do passthrough to the underlying data object. there's nothing more stupid that taking a native data structure (e.g. a C++ list, a python array, some app-specific creation, etc) and having to copy the data out of it into some GObject-based data structure before being able to give it to the TreeView. well, ok, Off topic, but I believe that's more or less how it works now. You can define your own model that implements the GtkTreeModelIface and TreeView will then display from that. You need to put your data items into GValues but you don't need to make GObjects for them. And the GValues only need to be made on demand for the items which are being sent for display (the current window), you don't need to pack the whole thing. John Lindgren posted a complete small example a few months ago (though I think he's missing set-fixed-height mode in that code): http://pastebin.com/45br5X3Z You can display *huge* datasets directly from your application's internal structures. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On 01/14/2012 12:53 AM, Michael Torrie wrote: On 01/13/2012 12:52 AM, Stefan Sauer wrote: TIP-DIALOG I've seen several implementations in aps (e.g. gimp has one). I did one for buzztard. It shows a random message from the tips list. I don't know of anyone who actually finds such a dialog useful to be honest. Many users I know sigh when they see that dialog when running an app for the first time, check never show this again and get their work done. In my opinion (only worth half a penny) such a feature is a waste of code in an app, and probably not worth the effort to implement in GTK. I agree that showing the tips as a startup dialog is somewhat annoying. On the other hand it would be useful to have a way to tell users about neat tricks and stuff and is not totally obvious. Sure, all of this can be documented in the manual, but apparently those are read even less often. Not sure if info bars that auto-hide after a while are better ... Stefan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Thu, 2012-01-12 at 11:23 +0100, Alexander Larsson wrote: On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote: snip 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). Gnome-contacts has one of these (at least in Gnome 3.2). Its not hard to do but would be nice to have in a single place. Also, it needs some help from the theme to look good, like adwaita does here: http://git.gnome.org/browse/gnome-themes-standard/commit/?id=90c4f48cf7720fb9b31e8388843a5fa6b8f3f705 Totem has a menu button as well, look for popup_button in: http://git.gnome.org/browse/totem/tree/browser-plugin/totem-plugin-viewer.c Hacky. 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. Not only does it help with animation, but its also nice in terms of size allocation. Often you want a set of widgets that can temporarily change into another set (for instance during editing) without causing a UI reflow. Having a widget stack like this helps with this size allocation handling. This is a problem in a number of control-center panels where we want widgets not to move when switching from one item's properties to another. Animation isn't the problem here, the problem is hide it but still take space in the layout. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
I think that if we were up to do this, we should go ahead and get rid of GtkTreeModel altogether and substitute it for something like libmodel. The data driven app situation in GObject/Gtk+ is quite sad at the moment and there's a lot of code that could be reused (like data/search filtering and data model backends) if we had a proper collection/data model API in place and used by the toolkit. 2012/1/13 Kristian Rietveld k...@loopnest.org On Jan 12, 2012, at 6:16 AM, Matthew Brush wrote: SIMPLE TREE and LIST It would be great to have simple GtkTree and GtkList widget sitting ontop of the extremely powerful GtkTreeView API for those many cases where you just need a basic tree or list box. The new widgets would not require a book[1] to explain how to use it. I saw a GtkTree in the API docs but it's deprecated, presumably because it doesn't sit ontop of the better tree view API. A couple of years ago I worked on an API and implementation of such a simple list/tree, using GtkTreeView internally. It never made it into GTK+ or bugzilla unfortunately and is catching dust on one of my machines. I still intend to dig up the code, document it and put it on a wiki somewhere for somebody to pick up and improve so that it can maybe be merged. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Fri, Jan 13, 2012 at 4:51 PM, Alberto Ruiz ar...@gnome.org wrote: I think that if we were up to do this, we should go ahead and get rid of GtkTreeModel altogether and substitute it for something like libmodel. The data driven app situation in GObject/Gtk+ is quite sad at the moment and there's a lot of code that could be reused (like data/search filtering and data model backends) if we had a proper collection/data model API in place and used by the toolkit. there is a bigger issue there, i think. in an ideal world, you don't want to base the date store for the TreeView on an object, but on an interface. then you want a series of adapters/wrappers that wrap data structures implemented in any language (or any language with a GTK binding) with the required interface. some of which might be null adapters that just do passthrough to the underlying data object. there's nothing more stupid that taking a native data structure (e.g. a C++ list, a python array, some app-specific creation, etc) and having to copy the data out of it into some GObject-based data structure before being able to give it to the TreeView. well, ok, there are lot of things that are a lot more stupid than that, but its still pretty aggravating. yes, i understand that GTK sits atop GObject in some fairly fundamental ways, but the TreeView is about displaying application data, not GTK state, and a much simpler mechanism for allowing the use of the data structures already in place in an app would be super-welcome. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Fri, 2012-01-13 at 21:51 +, Alberto Ruiz wrote: I think that if we were up to do this, we should go ahead and get rid of GtkTreeModel altogether and substitute it for something like libmodel. As long as it's not libmodel, or anything that requires encapsulating the value inside a GObject. (e.g. ModelString, ModelFloat, ModelInteger, ModelBoolean). -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Fri, 2012-01-13 at 17:21 -0500, Paul Davis wrote: On Fri, Jan 13, 2012 at 4:51 PM, Alberto Ruiz ar...@gnome.org wrote: I think that if we were up to do this, we should go ahead and get rid of GtkTreeModel altogether and substitute it for something like libmodel. The data driven app situation in GObject/Gtk+ is quite sad at the moment and there's a lot of code that could be reused (like data/search filtering and data model backends) if we had a proper collection/data model API in place and used by the toolkit. there is a bigger issue there, i think. in an ideal world, you don't want to base the date store for the TreeView on an object, but on an interface. then you want a series of adapters/wrappers that wrap data structures implemented in any language (or any language with a GTK binding) with the required interface. some of which might be null adapters that just do passthrough to the underlying data object. there's nothing more stupid that taking a native data structure (e.g. a C++ list, a python array, some app-specific creation, etc) and having to copy the data out of it into some GObject-based data structure before being able to give it to the TreeView. well, ok, there are lot of things that are a lot more stupid than that, but its still pretty aggravating. yes, i understand that GTK sits atop GObject in some fairly fundamental ways, but the TreeView is about displaying application data, not GTK state, and a much simpler mechanism for allowing the use of the data structures already in place in an app would be super-welcome. Additionally, if we were to go down this path, having the ability to have sections would be lovely. The way this seems to get done now is with dummy rows that get styled differently by the cell renderers and extra work to avoid selections. This means that you have little to no consistency between applications. Also, it should be styled by the css themes. Essentially, something like the sections in the Nautilus sidebar. However, it would need to scale slightly better since one might use it to group emails by day, week, month, etc. -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On 01/13/2012 12:52 AM, Stefan Sauer wrote: TIP-DIALOG I've seen several implementations in aps (e.g. gimp has one). I did one for buzztard. It shows a random message from the tips list. I don't know of anyone who actually finds such a dialog useful to be honest. Many users I know sigh when they see that dialog when running an app for the first time, check never show this again and get their work done. In my opinion (only worth half a penny) such a feature is a waste of code in an app, and probably not worth the effort to implement in GTK. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
Hopefully this isn't getting old, but I'm sort of just throwing these out there as I think of them. ROUND BUTTON This one might be a stretch, but is probably solvable with some CSS classes that are guaranteed to be there. Sometimes you want a button that is a circle. Buttons for a Phone Dialer or a record button might be good examples of when to use it. Arguably, this might fall under the not common enough category. BACKGROUND OPACITY It would be nice to have the ability to alter the opacity of a window without altering the opacity of GdkWindow'd widgets inside it. This is useful for utility windows that float over a primary window. Right now, you have to handle changes with the visual and/or screen and modify the background yourself. This breaks possible theming and is tedious. http://www.pixelmator.com/ is a good example of why this might be useful. CELL RENDERER BOX GtkCellAreaBox being a GtkOrientable helps for very basic things in a GtkTreeView such as a single column like: Title [==50% ] Description But it doesn't allow for more complex layouts per line. My understanding is that the following isn't possible using built-in objects from Gtk. Title Today [==50% ] Description We need a GtkCellRendererBox that allows packing cells within the cell. (Spare me the Yo, Dawg meme). FAST/SMOOTH SCROLLING (POSSIBLY INFINITE SCROLLING) A sort of container widget that handles keeping a couple pages to either side of the visible region in server side pixmaps. It would handle calling back to render various pages as needed based on scrolling. This could be useful for preview applications like Evince, Abiword, or slideshows. Possibly even reusable by GtkTextView/GtkTreeView. -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote: 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. There is some level of validation in the gtk+ printing dialog. The printer configuration files (PPD files) can specify certain combination of enabled features as incompatible (i.e. can't do full duplex while stapling or whatnot). Whenever something is invalid we show a label somewhere explaining the problem and then each problematic settings widget gets a warning icon. This is imho a pretty nice way to handle validation. You're not unable to input invalid input (which can be confusing), but you get instant feedback on when and what is invalid. 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). Gnome-contacts has one of these (at least in Gnome 3.2). Its not hard to do but would be nice to have in a single place. Also, it needs some help from the theme to look good, like adwaita does here: http://git.gnome.org/browse/gnome-themes-standard/commit/?id=90c4f48cf7720fb9b31e8388843a5fa6b8f3f705 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. Not only does it help with animation, but its also nice in terms of size allocation. Often you want a set of widgets that can temporarily change into another set (for instance during editing) without causing a UI reflow. Having a widget stack like this helps with this size allocation handling. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
Hey guys, about the MENU_BUTTON: we also have something like this in gedit see http://git.gnome.org/browse/gedit/tree/gedit/gedit-status-combo-box.c but it sucks because we can't search on it, it would be great having something like this that also allows you to search like a treeview, we were even thinking about using a popup with a treeview inside. So if this kind of widget with all use cases is pointed out in gtk+ would be much appreciated. Regards. On Thu, Jan 12, 2012 at 11:23 AM, Alexander Larsson al...@redhat.comwrote: On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote: 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. There is some level of validation in the gtk+ printing dialog. The printer configuration files (PPD files) can specify certain combination of enabled features as incompatible (i.e. can't do full duplex while stapling or whatnot). Whenever something is invalid we show a label somewhere explaining the problem and then each problematic settings widget gets a warning icon. This is imho a pretty nice way to handle validation. You're not unable to input invalid input (which can be confusing), but you get instant feedback on when and what is invalid. 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). Gnome-contacts has one of these (at least in Gnome 3.2). Its not hard to do but would be nice to have in a single place. Also, it needs some help from the theme to look good, like adwaita does here: http://git.gnome.org/browse/gnome-themes-standard/commit/?id=90c4f48cf7720fb9b31e8388843a5fa6b8f3f705 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. Not only does it help with animation, but its also nice in terms of size allocation. Often you want a set of widgets that can temporarily change into another set (for instance during editing) without causing a UI reflow. Having a widget stack like this helps with this size allocation handling. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Thu, Jan 12, 2012 at 7:23 PM, Alexander Larsson al...@redhat.com wrote: On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote: 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. There is some level of validation in the gtk+ printing dialog. The printer configuration files (PPD files) can specify certain combination of enabled features as incompatible (i.e. can't do full duplex while stapling or whatnot). Whenever something is invalid we show a label somewhere explaining the problem and then each problematic settings widget gets a warning icon. This is imho a pretty nice way to handle validation. You're not unable to input invalid input (which can be confusing), but you get instant feedback on when and what is invalid. This is a very good point, it would be great to incorporate some basic validation mechanisms in GTK+, in many cases form style validation is possible, i.e. one can fire up a dialog and hit the Apply or Commit button at which time entry validation can take place, but in some cases that's just really annoying (i.e. who needs to waste time with the extra step of firing up a dialog and hitting a Commit button). While configuration dialogs definitely fall into the first category, many editor applications such as user interface designers or image manipulation programs have property editors available at all times. In these cases validation should always happen synchronously. I think the warning icon with tooltip is a good idea, I've also considered changing an entry's background color to be red while invalid input is entered (of course this requires that the theme define what is a proper error color...) One classical error we should keep in mind is that entry validation at focus-out time is just not stable, in many cases for instance you get a situation where: a.) User selects object b.) As a consequence, current values are set in the editor widget c.) User enters invalid input d.) User selects another object e.) New values are entered into the editor frame f.) Finally, after old input is potentially lost, the focus-out event is finally delivered and validation is no longer possible or logical This is a common problem in multiple platforms and toolkits, it would be great IMO to have some backing support from the toolkit to help developers to get it right the first time. Cheers, -Tristan 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). Gnome-contacts has one of these (at least in Gnome 3.2). Its not hard to do but would be nice to have in a single place. Also, it needs some help from the theme to look good, like adwaita does here: http://git.gnome.org/browse/gnome-themes-standard/commit/?id=90c4f48cf7720fb9b31e8388843a5fa6b8f3f705 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. Not only does it help with animation, but its also nice in terms of size allocation. Often you want a set of widgets that can temporarily change into another set (for instance during editing) without causing a UI reflow. Having a widget stack like this helps with this size allocation handling. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
Benjamin Otte otte at gnome.org writes: One thing I've been wondering about is what features GTK is missing. This is mostly about developer-visible APIs, ie new widgets, and not about internal changes. I have some ideas from IRC discussions, mails and applications, but of course there might be big things I'm missing. UNDO A full undo/redo stack may belong in glib, but I'd be happy enough if TextView and TextEntry supported it SPELL CHECKING Once again, a full spell checking api may belong in glib, but I'd be happy enough to have it in gtk and easily enabled for TextView and TextEntry Ciao Paolo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Thu, Jan 12, 2012 at 6:32 AM, Paolo Borelli pbore...@katamail.com wrote: UNDO A full undo/redo stack may belong in glib, to me, this is highly unrealistic. undo/redo is incredibly application (and scale) specific. even inside one application, it can make sense to find two entirely different approaches to handling undo/redo (e.g. one based on save/restore of the full state of objects and other based on storing differences in state). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On 12 January 2012 12:17, Paul Davis p...@linuxaudiosystems.com wrote: to me, this is highly unrealistic. undo/redo is incredibly application (and scale) specific. even inside one application, it can make sense to find two entirely different approaches to handling undo/redo (e.g. one based on save/restore of the full state of objects and other based on storing differences in state). Tasks has a undo manager/undoable implementation and that's implemented by function pointers that do the right thing, so you can probably implement both methods with that. (http://git.gnome.org/browse/tasks/tree/libkoto) Ross ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Thu, Jan 12, 2012 at 7:31 AM, Ross Burton r...@burtonini.com wrote: Tasks has a undo manager/undoable implementation and that's implemented by function pointers that do the right thing, so you can probably implement both methods with that. well, sure. i guess i was assuming that much. maybe i'm just thinking too much about how you actually implement undo/redo, not what the API for undo the last change or redo the last undone thing looks like. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Wed, Jan 11, 2012 at 09:16:10PM -0800, Matthew Brush wrote: SIMPLE TREE and LIST It would be great to have simple GtkTree and GtkList widget sitting ontop of the extremely powerful GtkTreeView API for those many cases where you just need a basic tree or list box. The new widgets would not require a book[1] to explain how to use it. I saw a GtkTree in the API docs but it's deprecated, presumably because it doesn't sit ontop of the better tree view API. I agree. Most of the time, only basic features of GtkTreeModel and GtkTreeView are needed. But conversely, more advanced features are missing in GtkTreeStore, and are present in GNode. For example, unlink a subtree and relink it at another place. With GtkTreeModel, we have to delete the rows and then reinsert them one by one. The access to the data of the tree is also easier with a GNode, if we want to traverse the tree to find the right place where to insert a new node for instance. It's not difficult to implement a custom GtkTreeModel that uses internally a GNode, but it would be nice to have a GNode-like for GtkTreeView. But I don't know if a lot of applications need this and currently use a custom GtkTreeModel. I've read some discussions (probably on this list) about moving the model of the TreeView in GLib/GIO. But in this case, will the new model be as flexible as the GNode? pgpRUWCV9DQWc.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
My 2p: DATA GRID I'd like to be able to display a grid of numbers with rectangular selection, a little like a spreadsheet. Unfortunately this is not possible with treeview. At the moment I use a fork of the ancient and broken GtkSheet widget, which is unfortunate. PLOTS As Jean said, goffice has a nice set of plotting widgets. I use them in my app and they work well and are easy to program. I've not tried doing an animated scrolling graph with them though. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Thu, Jan 12, 2012 at 9:37 PM, Paul Davis p...@linuxaudiosystems.com wrote: On Thu, Jan 12, 2012 at 7:31 AM, Ross Burton r...@burtonini.com wrote: Tasks has a undo manager/undoable implementation and that's implemented by function pointers that do the right thing, so you can probably implement both methods with that. well, sure. i guess i was assuming that much. maybe i'm just thinking too much about how you actually implement undo/redo, not what the API for undo the last change or redo the last undone thing looks like. Actually, my latest attempt at undo/redo, after analyzing the difficulties which cropped up in Glade I've recently taken a wildly different approach. Hint, validation of whether a newly created command is a key point in a data-model centric undo/redo system, there is much pain involved when trying to mount an api layer on top of an undo/redo system which interacts with the data model. In this light I've decided to make my data models themselves implement an executable interface, depending on object state and of course, object type in a complex hierarchical model, an executable object can simply refuse to create a command which operates on the model. I've found this greatly reduces complexity in policing command validity (for instance if I were to apply this to Glade, then a derived widget adaptor for say, a GtkBin widget could simply refuse to create a command which adds a second child to the widget... in the process it could even pop-up a dialog informing the user why his request was impossible... Glade is a good example here because there can be many specific cases where a command would fail... centralizing that check work on the widget adaptors make's a lot of sense). Possibly it makes sense for GtkTextView to implement it's own undo/redo system internally, if it can be assumed that the text view (or text buffer more likely) is really only modifying text. However it would be good to be able to disable that feature, consider for instance an elaborate implementation of GtkSourceView: perhaps in that case there are many portions of text, but also perhaps the underlying buffer implementation should be implemented with symbol objects, possibly making reference to objects constructed/introspected from a loaded gir file... in that case implementing undo/redo on a code structure data model that is displayed in a derived GtkTextView should be done separately from the base only text implementation. Anyway, some food for thought... Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Jan 12, 2012, at 3:32 AM, Paolo Borelli wrote: Benjamin Otte otte at gnome.org writes: One thing I've been wondering about is what features GTK is missing. This is mostly about developer-visible APIs, ie new widgets, and not about internal changes. I have some ideas from IRC discussions, mails and applications, but of course there might be big things I'm missing. UNDO A full undo/redo stack may belong in glib, but I'd be happy enough if TextView and TextEntry supported it SPELL CHECKING Once again, a full spell checking api may belong in glib, but I'd be happy enough to have it in gtk and easily enabled for TextView and TextEntry It already exists as an add-on package: http://gtkspell.sourceforge.net It works quite well, and has recently been revived under a new maintainer after languishing for a couple of years. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Thu, 2012-01-12 at 09:24 -0800, John Ralls wrote: On Jan 12, 2012, at 3:32 AM, Paolo Borelli wrote: SPELL CHECKING Once again, a full spell checking api may belong in glib, but I'd be happy enough to have it in gtk and easily enabled for TextView and TextEntry It already exists as an add-on package: http://gtkspell.sourceforge.net It works quite well, and has recently been revived under a new maintainer after languishing for a couple of years. There's an old bug with patches still open for adding spell checking support to GTK+ -- although GIO would be a better fit these days. https://bugzilla.gnome.org/show_bug.cgi?id=383706 The discussion got bogged down in some tangent about word-splitting, but several years ago I took Marco's GSpell patches and adapted them for GtkHtml and they've been working splendidly for Evolution ever since. The API uses iso-codes to extract language names and enchant for the actual spell-checking. http://git.gnome.org/browse/gtkhtml/tree/components/editor (toward the bottom -- gtkhtml-spell-*) Matthew Barnes ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote: 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. Another +1 for plots, in particular a scrolling plot widget. I maintain a bit of scientific software for University and they all use real-time scrolling line charts. The basic requirements are * good performance (Christians was the best performing of those I tried) * multiple traces * autoscale * independently (of incoming data) adjustable scrolling speed * introspectable / usable from python[1] 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). And this too (if you are describing the wrench menu on chrome for example). John [1] Access from python because they get used in association with numpy, which is used for the static plots. In the end I chose to maintain a fork of the old rtgraph pygtk package https://github.com/nzjrs/rtgraph ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On 01/12/2012 03:59 AM, Benjamin Otte wrote: One thing I've been wondering about is what features GTK is missing. This is mostly about developer-visible APIs, ie new widgets, and not about internal changes. I have some ideas from IRC discussions, mails and applications, but of course there might be big things I'm missing. TIP-DIALOG I've seen several implementations in aps (e.g. gimp has one). I did one for buzztard. It shows a random message from the tips list. The 'random' part remembers which one has been shown already and selects random messages from the not yet shown tips. In the dialog one can ask for another tip or dismiss it. One more thing I planned is to have a link to the help or a link to some online resource optionally associated with each tip. I was also thinking of optionally having a picture shown next to the tip (like saying machine icons have context menus and showing an image with a opened context menu next to a machine icon.). SCALE widget with defined fill-start I brought that up when fill was added to range widgets, but my comment was ignored. Imagine a panorama scale widget - range is [left (-100) - middle (0) - right (100)] - t would be awesome if I could tell that fill-start is at 0.0 and the fill is drawn towards left or right depending on the value. for developers - find a way to make gtk-parasite work with modal dialogs (and maybe include it with gtk or advertise it more - a tools section on http://www.gtk.org/ having gtkparasite, glade, devhelp ... ?) Stefan Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RFC: new features
One thing I've been wondering about is what features GTK is missing. This is mostly about developer-visible APIs, ie new widgets, and not about internal changes. I have some ideas from IRC discussions, mails and applications, but of course there might be big things I'm missing. So personally, I consider a feature useful for inclusion in GTK if: A) ... it is useful to a lot of people This explains itself. B) ... it belongs into the widget toolkit realm There's a bunch of functionality that either belongs into a lower layer (see all the things in glib for examples of that) or into a higher layer (an example would be Webkit). C) ... it is provided by other toolkits successfully If there is another toolkit that has this functionality and people use it, that's a good indicator that people may want to use a similar feature with GTK. Of course, the opposite is also true: If other toolkits provide the feature and it sucks or nobody uses it, there's a high chance that it really is a bad idea. One important note here: I do consider the web (aka HTML5) a toolkit. D) ... it's hard to get right Some features look very simple, but are incredibly hard to get right. An example here is text layout. It's not just hard to get right, it also has a lot of corner cases in languages that developers do not speak themselves so will have no clue about. E) ... getting it right can have lots of benefits Some things can F) ... it is portable Some features are very specific to a certain platform and cannot be easily ported - such features are usually best kept in per-platform libraries and not shipped in the default. Of course, we always have exceptions, just look at GtkSocket and GtkPlug. G) ... inclusion has a benefit to GTK Again, Webkit is a good example: Including it in GTK would certainly be a good thing to do, but having GTK link against a browser engine would complicate the build process, increase the size of libgtk and add a lot of code to maintain. So it's rather beneficial to have it not part of GTK. And with these caveats, I'll go on and list the features and my personal opinions about them - why they are not yet part of GTK and why they should or should not be. As always, feel free to disagree or list more features that you think might be worthwhile. DOCK http://developer.gnome.org/gdl/stable/gdl-main.html A docking widget is something I've always missed in GTK, in particular one with powerful reordering, and UI adaptation capabilities. The main reason this has never happened is that it's a feature for huge applications with lots of toolboxes, like the GIMP, Inkscape or Anjuta. And those applications usually go their own way instead of converging on a common UI. Also, a dock is often a bad answer in UI design if your application is not complex. And if it's included as a general widget in GTK, it might encourage too many people to use it. And then we're stuck with bad UIs everywhere. So my feel is that a docking widget is unlikely unless the big players cooperate on developing one and propose it for inclusion. CANVAS https://live.gnome.org/ProjectRidley/CanvasOverview For a canvas pretty much the same reasons apply that apply for the dock: The people that really need one are the people writing complex applications and tose people have very different needs, so they end up writing their own. What makes this worse though is that GNOME 2 had a canvas and nobody used it (or better: everybody forked it). And then there were a lot more canvas libraries, but they didn't go anywhere either. Additionally, GTK is moving to being a canvas itself. So there is very little push from inside GTK to add an extra Canvas widget, but more push to make GTK better internally to be a canvas. My feel is that a separate canvas widget will never happen. But GTK will probably be good enough to not require a separate canvas anymore. OPENGL http://projects.gnome.org/gtkglext/ A lot of people would like to embed existing OpenGL solutions into GTK. As far as I can see it's one of the most-requested features from developers. But OpenGL is a very bad library for integrating with. And a lot of the OpenGL implementations are pretty bad (and the libgl writers than blame that on the GPUs. So nobody wants to support and maintain a binding of GTK to OpenGL, in particular because there is not just one binding to maintain but one for each platform/GL implementation. I would really like to see this feature happen, but the lack of commitment from developers seems to not make this happen any time soon. VIDEO PLAYER One of the things that is really hard to do is getting a video player working. It's doable with GStreamer if all you care about is displaying the video in a rectangular area of your screen, but once you want to overlay widgets, put videos in cell renderers or do other interesting things, stuff gets hairy. Looking at the existing solutions, Totem has switched to Clutter and Epiphany's multimedia support failed me spectacularly on http://cuttherope.ie/
Re: RFC: new features
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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
Le jeudi 12 janvier 2012 à 03:59 +0100, Benjamin Otte a écrit : 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. Gnumeric uses Goffice for plots. Anybody can use it, and it can be expanded to support new plot types relatively easily. Of course we still have a license issue with Goffice (https://bugzilla.gnome.org/show_bug.cgi?id=463248). Best regards, Jean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On 01/11/2012 06:59 PM, Benjamin Otte wrote: [...] And with these caveats, I'll go on and list the features and my personal opinions about them - why they are not yet part of GTK and why they should or should not be. As always, feel free to disagree or list more features that you think might be worthwhile. DOCK [...] I've always felt something like this was missing from GTK+. I think I remember seeing a cool widget for this in Qt the last time I poked around in their RAD tool (I don't know Qt at all). VIDEO PLAYER [...] Along with this, it would be great to have YUV-ish support in Cairo that could somehow avoid or minimize converting a whole frame between colorspaces (ex. YUV to RGB) and make use of hardware YUV support. I'm not sure if that even makes sense, since probably lots of code depends on working in another colorspace, but it would make real-time video easier to get right (ie. not slow). What about a more general GtkVideoCanvas widget that can help out here and maybe have a separate sink plugin in GStreamer that can pull frames from a pipeline and render to the canvas. Then it's not restricted to just being useful for Gstreamer apps but can be if using Gstreamer. Applications could choose to just use V4L2, DShow or libav* directly and render onto the canvas, for example. Each new frame could cause an expose/draw signal giving the chance to do OSD on it with Cairo. Here's a couple more ideas: SIMPLE TREE and LIST It would be great to have simple GtkTree and GtkList widget sitting ontop of the extremely powerful GtkTreeView API for those many cases where you just need a basic tree or list box. The new widgets would not require a book[1] to explain how to use it. I saw a GtkTree in the API docs but it's deprecated, presumably because it doesn't sit ontop of the better tree view API. TAB BUTTONS I think Tristan alluded to this in another thread, but there is a common need for a compact button that can fit into small places such as a notebook tab. It's feels really dirty doing it yourself. This could be used in the next one... NOTEBOOK IMPROVEMENTS See Firefox. I think that's it. Cheers, Matthew Brush [1] http://scentric.net/tutorial/treeview-tutorial.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On Thu, Jan 12, 2012 at 1:38 PM, Christian Hergert ch...@dronelabs.com wrote: 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. 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] 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
