Runtime environment for GTK+ application
I'm learning GTK developement on a Windows XP machine. I was able to successfully build a simple hello world and I read about the need to include more than the plain exe file if I want to distribute my application to someone else. I have two question somehow related. First: I can't find a precoocked package or at least a best practice document on which files are needed to distribute with my application, can someone point me on the right direction, please? Second ancd very similar to the first: I know my hello world is working because I copied the exe file in the bin directory of my GTK installation. I was expecting I can run it from any folder in my computer because I put the GTK installation base folder in my path though, but I get some dll error. Do I forgot something during the GTK installation? TIA Reer SpA Tel. +39 011 2482215 Fax. +39 011 859867 L'utilizzo non autorizzato del presente messaggio e' vietato e potrebbe costituire reato. Se il presente messaggio non e' a Lei indirizzato, il suo contenuto non deve essere considerato come trasmesso o autorizzato dalla Reer SpA; in tale caso Le saremmo grati se, via e-mail, ce ne comunicasse l'errata ricezione. The unauthorized use of this e-mail is prohibited and could constitute an offence. If you are not the intended recipient of this message its contents shall be understood as neither given nor endorsed by Reer SpA. Please notify Reer SpA by e-mail immediately in that case. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Runtime environment for GTK+ application
Manuel Ferrero wrote: First: I can't find a precoocked package or at least a best practice document on which files are needed to distribute with my application, can someone point me on the right direction, please? You can either take Dov's approach and package the GTK DLLs in your installer, or you can use a pre-packaged installer: http://downloads.sourceforge.net/gtk-win/gtk2-runtime-2.24.8-2011-12-03-ash.exe?download I am assuming you are using GTK 2.24.8 (as you should on Windows). Second ancd very similar to the first: I know my hello world is working because I copied the exe file in the bin directory of my GTK installation. I was expecting I can run it from any folder in my computer because I put the GTK installation base folder in my path though, but I get some dll error. Do I forgot something during the GTK installation? The bin folder of your GTK DLLs needs to be in the %PATH% of your Windows environment. The pre-packaged installer I linked to above will set that up for you, or you can do it manually. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Runtime environment for GTK+ application
On 01/12/2012 04:38 PM, Manuel Ferrero wrote: I'm learning GTK developement on a Windows XP machine. I was able to successfully build a simple hello world and I read about the need to include more than the plain exe file if I want to distribute my application to someone else. I have two question somehow related. First: I can't find a precoocked package or at least a best practice document on which files are needed to distribute with my application, can someone point me on the right direction, please? Second ancd very similar to the first: I know my hello world is working because I copied the exe file in the bin directory of my GTK installation. I was expecting I can run it from any folder in my computer because I put the GTK installation base folder in my path though, but I get some dll error. Do I forgot something during the GTK installation? Another link to some useful info: http://www.gtk.org/download/win32.php You may also want to check/use this runtime (although it's GTK+ 2.22.0) I use for several of my apps: http://www.newsrssticker.com/src/gtk2-win32-runtime-bin.tar.gz Extra info about building app/installer on win32 is available on the site (http://www.newsrssticker.com/help.php#building_from_source_howto). -- Emmanuel Thomas-Maurin manutm...@gmail.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtkEntry, a virtual keyboard and overwriting problems
Hi there, I wanted to implement a virtual keyboard using individual letter buttons and have the string constructed displayed in the gtkEntry widget. entry=gtk_entry_new(); // create the entry widget GdkEvent new_event; // the gdkevent to put I used the following approach when a button was clicked : gtk_widget_grab_focus(entry); new_event.key.window = gtk_widget_get_parent_window(entry); new_event.key.keyval = c[0]; // take only the first letter gdk_event_put(new_event); I found that every time I clicked a letter button, such as 'a', the letter 'a' would be displayed in the entry widget - great ! but If I try to add a second letter, such as 'b', the letter 'a' would be overwritten by 'b'. Not so good ! I need to construct strings in the GtkEntry widget ... can anyone see what I am doing wrong ? When I use the same approach with the GtkTextView widget it works OK : entry=gtk_text_view_new (); // create the text view widget The following works correctly - I can create strings: gtk_widget_grab_focus(entry); new_event.key.window = gtk_widget_get_parent_window(entry); new_event.key.keyval = c[0]; // take only the first letter gdk_event_put(new_event); The problem with this approach is that it is overly complex, I only want the user to input a single line of text and it is harder to extract the string from the GtkTextView widget ... any pointers ? thanks Matt ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkEntry, a virtual keyboard and overwriting problems
For those who are interested, here is the state of the event : new_event.key.type = GDK_KEY_PRESS; new_event.key.send_event = TRUE; new_event.key.time = GDK_CURRENT_TIME; new_event.key.state = 0; //GDK_KEY_PRESS_MASK; new_event.key.length = 0; new_event.key.string = 0; new_event.key.hardware_keycode = 0; new_event.key.group = 0; On 13/01/12 10:55, Matt Flax wrote: Hi there, I wanted to implement a virtual keyboard using individual letter buttons and have the string constructed displayed in the gtkEntry widget. entry=gtk_entry_new(); // create the entry widget GdkEvent new_event; // the gdkevent to put I used the following approach when a button was clicked : gtk_widget_grab_focus(entry); new_event.key.window = gtk_widget_get_parent_window(entry); new_event.key.keyval = c[0]; // take only the first letter gdk_event_put(new_event); I found that every time I clicked a letter button, such as 'a', the letter 'a' would be displayed in the entry widget - great ! but If I try to add a second letter, such as 'b', the letter 'a' would be overwritten by 'b'. Not so good ! I need to construct strings in the GtkEntry widget ... can anyone see what I am doing wrong ? When I use the same approach with the GtkTextView widget it works OK : entry=gtk_text_view_new (); // create the text view widget The following works correctly - I can create strings: gtk_widget_grab_focus(entry); new_event.key.window = gtk_widget_get_parent_window(entry); new_event.key.keyval = c[0]; // take only the first letter gdk_event_put(new_event); The problem with this approach is that it is overly complex, I only want the user to input a single line of text and it is harder to extract the string from the GtkTextView widget ... any pointers ? thanks Matt ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Need control of filename entry area in gtkfilechooser
When I type in the filename into the filename entry area in gtkfilechooser dialog, I want to intercept the text that is entered, modify it and then display it in the filename area. How do I do this? For a regular text buffer, I know how to do this: I can do a gtk_text_view_get_buffer and then have a callback for insert-text. I can then modify the text that is entered and then insert it into the buffer, all from inside the callback. I want to be able to achieve the same thing for filename entry. Does anyone know how to do this? Thanks, -Ferdinand ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-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: gobject-introspection and GBoxed
On Wed, Jan 11, 2012 at 14:47, jcup...@gmail.com wrote:
Hi all,
I'm adding gobject-introspection support to my library. It's working
well for the GObject classes, but I just can't get it to work for
GBoxed objects. I'm sure I'm missing something obvious. Do I need to
write an override to make a class for the type myself?
I've spent some time googling and grepping around and not found a
simple example. Again, I'm probably being stupid.
I'm doing something like this in a header:
/**
* VIPS_TYPE_BLOB:
*
* The %GType for a #VipsBlob.
*/
#define VIPS_TYPE_BLOB (vips_blob_get_type())
GType vips_blob_get_type( void );
typedef ... VipsBlob;
VipsBlob *vips_blob_new( int n );
and this in the .c file:
GType
vips_blob_get_type( void )
{
static GType type = 0;
if( !type )
type = g_boxed_type_register_static( VipsBlob,
(GBoxedCopyFunc) ...,
(GBoxedFreeFunc) ... );
return( type );
}
/**
* vips_blob_new:
* @n:
*
* Returns: (transfer full): the new #VipsBlob.
*/
VipsBlob *
vips_blob_new( int n )
{
return (...a new VipsBlob);
}
Now when I start up Python I get this:
from gi.repository import Vips
Vips.blob_new
function blob_new at 0x77e31de8
Vips.blob_new(12)
Program received signal SIGSEGV, Segmentation fault.
_args_cache_generate (callable_cache=0x9b04c0, callable_info=0xa6d280)
at /build/buildd/pygobject-3.0.0/gi/pygi-cache.c:1282
This is on current Ubuntu, so:
$ pkg-config gobject-introspection-1.0 --modversion
1.30.0
Looks like a bug in pygobject, could you file a bug with a backtrace?
It may be worth trying out with the latest release to scope better the problem.
Thanks,
Tomeu
John
___
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
