Re: colors in treeview
Karel Honzl wrote: Is it possible to create treeview in which I can set color (text color) of certain row? I want to hightlight some rows. You may want to take a look at the way GtkCellRenderers [1] work. Before rendering a particular row, your tree view sets the attributes registered with gtk_tree_view_insert_column_with_attributes on the cell renderer based on the column data you specified, afterwards requesting a render. The properties not registered with the GtkTreeView are used for rendering but not modified by the tree view. For instance for getting bold text, you can set the weight attribute of the cell renderer to PANGO_WEIGHT_BOLD, and add a new boolean column to your model which is passed as weight-set attribute column inside the treeview registration call. If you don't want to mess around with additional columns, and your weight-set value depends on the state of some object, you can also use gtk_tree_view_insert_column_with_data_func for the column and manually set all the attributes based on the object state. [1] http://developer.gnome.org/doc/API/2.0/gtk/GtkCellRendererText.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Problem with popup menus and highlighted items in TreeView
On Wed, Jan 18, 2006 at 10:02:30PM -0600, Gabriel Burt wrote: I have a TreeView (F-Spot's tag list) that has a popup menu. If I have a tag (row) selected and then right-click on a different tag, it first pops up the menu, then (the default handler) selects all the tags in between the two tags. The problem is I need to know how many tags are highlighted to customize the popup menu, but because of the ordering of these operations, I get the wrong value. Is the only answer to not use the default handler and do the selection logic (shift/ctrl) myself? g_signal_connect_after() does not help? Yeti -- That's enough. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Blocking a signal with unknown handler id?
On Wed, 2006-01-18 at 20:50 +, John Cupitt wrote: You can block by callback data: http://developer.gnome.org/doc/API/2.0/gobject/gobject-Signals.html#id2725984 There's a handler search thing too. On Thu, 2006-01-19 at 08:39 +0100, Christian Neumair wrote: You may want to try g_signal_lookup and g_signal_handlers_block_matched where only G_SIGNAL_MATCH_ID is passed. Thanks! One of those ought to solve my problem... I'll check them out. -- Daniel Pekelharing [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
re: dialogs problems
Ok, im sending some source code so its easy to see:
This is the main menu callback, it opens the first dialog:
void on_prov_admin_activate (GtkMenuItem *menuitem, gpointer
user_data)
{
gtk_widget_show(create_prov_admin_dlg());
}
This is a callback from a button inside prov_admin_dlg:
void on_prov_admin_edit_clicked (GtkButton *button,
gpointer user_data)
{
gint selected;
GnomeDbGrid *grid;
GtkWidget *dialog;
grid=GNOME_DB_GRID(lookup_widget(GTK_WIDGET(button),prov_dbgrid));
/* Si no hay seleccion, salir */
if ((selected=gnome_db_grid_get_selected(grid))0)
return;
boa_fe.editing=TRUE; /* Global flag */
boa_fe.id=gnome_db_grid_get_selected_id(grid); /* Global ID */
dialog=create_new_prov();
ret=gtk_dialog_run(GTK_DIALOG(dialog)); /* Block on edit dialog */
gtk_widget_destroy(dialog);
boa_fe.editing=FALSE;
fill_prov_dbgrid(GTK_WIDGET(button)); /* Refresh the dbgrid*/
}
That opens the second dialog (third window).
And inside new_prov dialog, I have this callback, wich is from the
Save button:
void on_new_prov_save_clicked (GtkButton *button, gpointer user_data)
{
GdaCommand *cmd;
gchar *buffer;
gint rows;
gint p_id, iva_id;
const gchar *cuit;
gchar *nombre;
GdaDataModel *recset;
cuit=gtk_entry_get_text(GTK_ENTRY(lookup_widget(GTK_WIDGET(button),new_prov_cuit)));
nombre=g_strdup(gtk_entry_get_text(GTK_ENTRY(lookup_widget(GTK_WIDGET(button),new_prov_nombre;
g_strchomp(nombre);
if (g_utf8_strlen(nombre,40)==0)
{
messagebox(Debe ingresar un nombre.); /* --- Here
is the problem */
gtk_widget_grab_focus(lookup_widget(GTK_WIDGET(button),new_prov_nombre));
return;
}
. . .
gda_command_free (cmd);
g_free(buffer);
}
Messagebox is this:
void messagebox(gchar *msg)
{
GtkWidget *dialog;
dialog = gtk_message_dialog_new_with_markup (NULL,
GTK_DIALOG_MODAL,
GTK_MESSAGE_QUESTION,
GTK_BUTTONS_OK,
msg,
NULL);
gtk_dialog_run (GTK_DIALOG (dialog));
gtk_widget_destroy(dialog);
}
Ok thats the source.
The problem is that when closing that last dialog from messagebox, the
new_prov dialog closes too and (i have experimented) returns the
response of messagebox.
The idea was to warn the user of a blank field and return so he can fill it.
Thanks all.
Saludos, Juan Pablo.
___
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Radio buttons - howto disable callback on deselect?
Hi all, Is there anyway to disable a radio button/menu-item calling the callback function when it gets deselected? In other words when the user selects an option, only call the callback for the newly selected radio item and not for the previously selected one (which is deselected)... Thanks in advance! -- Daniel Pekelharing [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Radio buttons - howto disable callback on deselect?
On 1/19/06, Daniel Pekelharing [EMAIL PROTECTED] wrote:
Hi all,
Is there anyway to disable a radio button/menu-item calling the callback
function when it gets deselected?
In other words when the user selects an option, only call the callback
for the newly selected radio item and not for the previously selected
one (which is deselected)...
You can use smth like this:
void
callback (GtkToggleButton *toggle)
{
if ( !gtk_toggle_button_get_active (toggle) )
return;
/* some other stuff */
}
Olexiy
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ printing dialog highlevel thoughts
On Wed, 2006-01-18 at 19:39 -0500, Michael Sweet wrote: Alexander Larsson wrote: (cc:ing some people who I think might be interested in this) I've just started looking at doing a printing dialog for Gtk+ 2.10. For some background thoughts from owen, see: http://mail.gnome.org/archives/gtk-devel-list/2005-October/msg00024.html FWIW, both Windows and MacOS X provide APIs for accessing the list of available printers, etc., and the CUPS API is also available on MacOS X. WRT Linux printing, CUPS is pretty much ubiquitous, and failing that you can standardize on PAPI (the SourceForge library apparently supports CUPS, LPR, and Solaris lp - check with Norm Jacobs for details...) I think relying on CUPS might be good enough. Opinions on this? Does e.g. solaris ship CUPS? * Printing photos This is (these days) a pretty common task, but substantially different from what the traditional print dialogs are made to support. We could make this a standard type of dialog simplifying such printing. See the e.g. the easy print dialog in OSX in the screenshots above. This type of printing functionality is also useful for a lot more than just image printing. Also, it would be really nice to allow any app to print N-up as well as poster printing (scaling and printing on multiple pages...) With a callback-driven printing mainloop i think this is pretty easy to do. The mainloop would just set the CTM and clip rect before calling the page rendering callbacks (multiple callbacks per physical page for N-up, and call the same callback for multiple physical pages for poster printing). Yes, there are a bunch of applications that want to do this, however in most cases you'll be better off sticking with the standard print path as generating good PS/PDF output is not trivial. I'd argue that the more we can do to improve the low-level print/file generation APIs (i.e. Cairo or whatever), the more likely it will be that apps will not need to bypass the standard paths. Look at what Apple has done with Quartz and the Print Manager APIs - by the sounds of things, Adobe will (finally) be moving away from using the old Carbon print APIs, and their apps use just about every trick in the book when printing... I think this is an fine long term goal. However we have to recognise the fact that there are currently apps (like OOo) that won't do this and we have to support these apps anyway. It makes sense to use the OS-supplied print dialogs when they are available and provide sufficient functionality, however there *is* no standard dialog on Linux (at least not yet :) so there is still the issue of coming up with a toolkit-neutral interface that can be used by all... Since this is the discussion of the gtk+ print dialog addition I think its fair to say that the linux/unix-specific dialog will be written in Gtk+. A toolkit-neutral dialog seems very hard to make from a technical standpoint, and its gonna have integration issues with all toolkits. Right, we've looked at doing something similar with FLTK as well... The same techniques for embedding windows in browsers, etc. will work with the print dialogs. Did you get any results from this? I.E. do you have some working code. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a gun-slinging umbrella-wielding master criminal gone bad. She's a violent punk widow in the wrong place at the wrong time. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib 2.10 / Pango 1.? for GNOME 2.14?
On Wed, 2006-01-18 at 10:21 -0600, Federico Mena Quintero wrote: Sorry that I dropped the ball on this, and haven't followed all the discussion. Other than Pango optimizations and and GSlice in Glib, is there a compelling reason to use the new Glib/Pango in GNOME 2.14? - Was the ABI issue resolved with respect to GObject floating references? Changing the object hierarchy sounds like a definite break to me. - There is no way yet to disable GSlice, so we can't valgrind apps. - Are there any apps using the new Glib APIs now? The new thread pool API I worked on with Sebastian is used in GnomeVFS from v2.13.4. -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ printing dialog highlevel thoughts
On Thu, 2006-01-19 at 10:39 +0100, Alexander Larsson wrote: FWIW, both Windows and MacOS X provide APIs for accessing the list of available printers, etc., and the CUPS API is also available on MacOS X. WRT Linux printing, CUPS is pretty much ubiquitous, and failing that you can standardize on PAPI (the SourceForge library apparently supports CUPS, LPR, and Solaris lp - check with Norm Jacobs for details...) I think relying on CUPS might be good enough. Opinions on this? Does e.g. solaris ship CUPS? Solaris ships PAPI. Doesn't ship CUPS. Laca ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ printing dialog highlevel thoughts
On 18 Jan 2006, at 19:07, Alexander Larsson wrote: (cc:ing some people who I think might be interested in this) I've just started looking at doing a printing dialog for Gtk+ 2.10. For some background thoughts from owen, see: http://mail.gnome.org/archives/gtk-devel-list/2005-October/ msg00024.html I've started studying various platform APIs and UIs, cups, PPDs, etc, preparing for this. To compare various platform and application printing dialogs I have put together a set of screenshots from Linux/OSX/Windows at: http://people.redhat.com/alexl/print_dialogs/ Some stuff here (including a 1hr WMV video) about Windows Vista printing too... no screenshots though unfortunately: http://channel9.msdn.com/Showpost.aspx?postid=137532 Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Directfb Backend
Sorry for being slow to respond to this. So, provided nobody speaks up against it (which I don't expect), I would like to invite you to merge the directfb backend into GTK+ for 2.10, considering that it is actively maintained, does compile, and is used (three things that cannot be said of the old framebuffer backend). As a first step, I would like to ask you to post patches for things which touch the configure machinery and any backend-specific things in gtk/ Also having some quick howto for building and testing this backend would be good (or is there a web page describing this already ?) Once we have the basic integration done and things are working, we should consider removing the framebuffer backend. There are some more things that need to be done for that, such as replacing the framebuffer backend specific doc sections with similar information for the directfb backend, etc. Regards, Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gnumeric on Scientific Linux
I recently had occasion to build gnumeric (1.4.3) on a Solaris 7 box used as a spectrometer controller. The dependency tree is a bit daunting, but possible. Details available (I took careful notes) - mailto:[EMAIL PROTECTED] The only reason you were able to do that is that I have been keeping Gnumeric and all its dependencies honest. I have been compiling on Solaris 2.8 for years. For me, the most difficult piece to resolve was a very old (ancient) X running on solaris, and the requirement for XFt and XRender. We did not use to require XRender. Could you check what is not requiring it, as opposed to just strongly suggesting it? Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
2006 X Window System Developer's Meeting --- XDevConf ---
ANNOUNCEMENT!
The next X Developer's Conference is scheduled on February 8-10, 2006
at Sun Microsystem's Santa Clara campus. These dates were arrived at
to be compatible with planning for other important conferences before
and after.
Please refer to http://wiki.x.org/wiki/XDevConf for the
latest updates on our planning.
=== Call for papers ===
To express your intent, please submit a title asap. Complete
abstracts are desireable but not required
Suitable topics include, but are not limited to:
o Updates on existing RD
o Drivers
o Input handling
o DRI/DRM
o GL in its various incarnations
o Performance
o Desktop development
o Application development
o Remote X and Thin Clients
As in previous events, we will make an effort to include developer talks
from the entire range of the desktop stack
=== HackFest and Breakout Sessions ===
Expect ample support for informal breakout sessions, hacking and
socializing
during this XDevConf.
At this time, we do not have a limit on the attendance. We still have
a choice of rooms, but we do need to develop a headcount as early as
possible. So, if you have either presented or attended previously,
or even considered attending previously, we would like to receive email
from you, expressing whether you do or do not expect to attend this year.
Looking forward to seeing you at the next X Developer's Conference in
sunny Santa Clara, CA!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Scrolling in GtkTreeView: very slow
Hello, my name is Samuel, from Sao Paulo, Brazil (my English is very bad!). My doubt is: Why scrolling in GtkTreeView is so slow??? My machine is a Via C3 800 MHz, with 256 MB of memory. My system is Debian Unstable, running IceWm. I load 3,000 lines in a GtkListStore and show them in a GtkTreeView. I set the fixed-height-mode property of the GtkTreeView to TRUE, and the list is showed fast. But, the problem is when I scroll the GtkTreeView. With mouse or keyboard, the scrolling is VERY slow, and eats a lot of processor! Is there any solution for this problem? Thanks, Samuel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib 2.10 / Pango 1.? for GNOME 2.14?
On Thu, 19 Jan 2006, Luca Ferretti wrote: Il giorno mer, 18/01/2006 alle 10.21 -0600, Federico Mena Quintero ha scritto: Sorry that I dropped the ball on this, and haven't followed all the discussion. Other than Pango optimizations and and GSlice in Glib, is there a compelling reason to use the new Glib/Pango in GNOME 2.14? Unicode 4.1 ? Yes, which is very important IMHO. Also Pango HEAD handles OpenType Latin (and other basic scripts) fonts. It also does cairo-fc hexbox drawing. That change deserves going into stable branch, but it was a non-obvious change and needed some porting work, so I didn't do myself. I think a better way to rephrase Federico's question is: should the floating stuff be rolled back? I think that was discussed and closed already. So we have a glib release that we want to not use?! The question is really about glib now. Pango is using some new stuff in latest glib, includeing g_slice, like many other modules do already.. --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtkspell (was Re: Announcing: Project Ridley)
I'm not a Gtk+ developer, but I think one of the criteria for being considered is: doesn't introduce a new library dependency, or maybe it can, if it really makes sense. Gtk+ depending on a spell checking library hardly makes sense, however. On Fri, 26 Aug 2005, Mike Hearn wrote: Yes, it's yet another me too post, this time for gtkspell. Spelling checker support is widely used in many apps, and from my POV is a huge pain because gtkspell is a very common failed dependency for autopackages. We provide tools to make weak linking against this library simple but a few projects for whatever mysterious reasons they have refuse to use them. Being able to guarantee the presence of GtkSpell by depending on GTK+ would be wonderful. Last time I asked about this, Owen indicated he didn't think it belonged in GTK+ but maybe this Project Ridely means a change in policy? thanks -mike Chipzz AKA Jan Van Buggenhout -- UNIX isn't dead - It just smells funny [EMAIL PROTECTED] Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
Il giorno dom, 21/08/2005 alle 00.50 -0400, Jonathan Blandford ha scritto: Now that GTK+-2.8.0 is out, the GTK+ team would like to announce Project Ridley. GOALS: The primary goal of Project Ridley is to cut down on the number of problem libraries that are part of the GNOME platform. We propose to do this by moving functionality into GTK+, wherever it makes sense. These libraries are generally small, undermaintained, and buggy. They have an unclear purpose (such as libgnome and libgnomeui), are copied-and-pasted around (such as libegg) or would benefit by being in GTK+ (libgnomeprint and libgnomeprintui.) Not well fitting with this disclaimer, but are any interesting widget in GIMP to include in Project Ridley? For instance the small cross-arrow between the vertical and the horizontal scrollbars, used to scroll the image when zoomed in showing a thumbnail, could be useful for other GNOME application related to image (eog, gthumb, f-spot) and document (evince) viewing. Could someone explore and report about GTK+ widgets in GIMP sources useful for other applications? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkAssistant API thoughts
Really new to this thread (and model), so if this is out-of-order, my appologies, but... - use a stack of visited pages as you do to implement back. I don't think there is a need to specify a custom back function, it should always go back to the previous page I can think of one instance where we needed a custom back. In RP3 (which was a modem configurator program) we had a page series that went: [ Search for modems? ] - [ Search progress ] - [ Results ] ^---/ We would probably do that better now, but just giving a data point. One could provide a pop function. This way Results, which knows the way it was gotten to, can modify the path back. Allowing any more manipulation of the stack (than pop) is probably overkill and possibly dangerious. Just a thought. - Joseph Kowalski ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtkNoteBook focus on creation ?
Hello, i'm lookin for a way to give focus to every newly created notebook tab, cause by default, the newly created don't have focus, only the first one has the focus. i tried with gtk_notebook_next_page() after the call to gtk_notebook_append_page(), but it doesn't seem to work ? ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Proposal for GTK+ advanced formatted entry and spinner API
Hi all. I would like to propose my idea for Format-Elements, that will be used to control GtkEntry and GtkSpinButton. The idea is to allow organized, element-based formatting of data displayed textually. The current common formatting methods include regular expressions and masking, and can be done either real-time (as you type) or offline (upon validation request, like a lose-focus-event). While these methods are sufficient in some places, they are very limited for the common uses as I see it. For example, the most common uses for formatted entries include a date/time entry and an IP address entry. With the lack of a good formatting method, these are implemented as a set of spin-buttons or with an offline-validators. It would look much nicer if there could be a formatted spin-button that could handle each of the elements separately, while maintaining the outputted, visible value as a simple textual string. What I would like to propose is as follows: 1. Define a base format_element structure that will dictate the interface. It will include methods for getting the value as a string (formatted to fit in a given minimum width), the minimum width (in characters) of the element, and scrolling methods (step up, step down, page up, page down, top, and bottom). It will also allow the programmer to define whether the element is editable or static (say, a separator or a format specifier, like the brackets in a phone-number). The format element also holds its own value. 2. Define several format elements implementing this interface, each handles a different type of data. There will be format elements to handle integer values, floating-point values, enumeration/completion strings, general strings, and others as needed. 3. Let GtkEntry contain a list of format elements (and the needed API to handle this list). The entry need to know what is the current focused format element (this can be done by checking the cursor position whenever it changes, using the notify::cursor_position event), and need to pass the element the character that the user wanted to enter. The only change in value in this case is done within the format-element. When a change in a format element occures, the entry need to rewrite itself by concatanating the values of all its format elements in order. 4. Let GtkSpinButton send the relevant scroll requests to the focused format-element. 5. Create a simple, non-programmative API for definition of the format (say, using a string in a defined format) that will internally create the needed format-elements and will add them to the list. This way, creating a date/time field will look something like this: GtkWidget *spinner; spinner = gtk_spin_button_new (); gtk_entry_add_format_element (spinner, gtk_format_element_int_new (1, 31)); // day gtk_entry_add_format_element (spinner, gtk_format_element_string_new_static (-)); // separator gtk_entry_add_format_element (spinner, gtk_format_element_int_new (1, 12)); // month gtk_entry_add_format_element (spinner, gtk_format_element_string_new_static (-)); // separator gtk_entry_add_format_element (spinner, gtk_format_element_int_new (0, )); // year gtk_entry_add_format_element (spinner, gtk_format_element_string_new_static ( )); // separator gtk_entry_add_format_element (spinner, gtk_format_element_int_new (1, 12)); // hour gtk_entry_add_format_element (spinner, gtk_format_element_string_new_static (:)); // separator gtk_entry_add_format_element (spinner, gtk_format_element_int_new (0, 59)); // minute gtk_entry_add_format_element (spinner, gtk_format_element_string_new_static (:)); // separator gtk_entry_add_format_element (spinner, gtk_format_element_int_new (0, 59)); // second gtk_entry_add_format_element (spinner, gtk_format_element_string_new_static ( )); // separator gtk_entry_add_format_element (spinner, gtk_format_element_enum_new (AM, PM, NULL)); (simply, adding the wanted format elements in the wanted order to the spin button.) The value of the spin-button could be taken as a string in this case, or a reference can be held to each of the non-static format elements, and its inner, real value can be used. This is my proposal, I would like to know what you think and receive comments about it. Itai. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some introspection on GtkContainer children.
Damon Chaplin wrote: On Thu, 2005-09-15 at 15:46 -0400, Tristan Van Berkom wrote: as specially noted that there are in effect three types of child widgets; normal, added as a result of a property value; added as a composite child which is constantly present. I think that if we're going to talk of ideal scenarios, GtkContainer should probably be a GInterface and allow for any object to have child objects; which also could be composite or not; children also tend to have different relationships to parents; for example a GtkMenuItem parented by a GtkMenu isnt exactly a GtkContainer -- GtkWidget relationship, its also concievable that a parent object can have multiple children of multiple relationship types. I think you guys should probably give up on the idea of handling standard GTK+ widgets generically. There are so many special cases that it is almost impossible. I second that, however only from a GUI designer point of view. In case of a library which constructs output from a GUI designer (eg libglade) it's not impossible to handle all non-deprecated widgets in gtk+ in a general way. There's not that much introspection information missing to do so. Basically a way of generically adding an object to another container like object and a way of getting an object out of a container using a string. Johan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
pie menu; key accelerators
New widget suggestion: * a pie (or radial) menu inherited from gtk.menu or gtk.menushell widgets. ( ref: http://en.wikipedia.org/wiki/Pie_menu ) Menu usability suggestion: * key accelerators accessible while menu is visible. ( ref: http://www.guidebookgallery.org/articles/acceleratorsandtoolbars ) Regard; Pedro Amaral Couto ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Success! Got gtk2 + xorg-modular built in SYSROOT-environment
Enrico Weigelt wrote: * Behdad Esfahbod [EMAIL PROTECTED] schrieb: Hi, I'm not quite sure what a SYSROOT environment is. It's a kind of jail, but for the toolchain instead of a running system: evrything's taken from within the sysroot, instead of the running system. Probably the cleanest way of building for an foreign system, not just for real crosscompiling. Sounds like installing an OS into a subdirectory, tweaking various config files, device files, mountpoints, etc. within that subdir's OS installation, and then chrooting into that dir to build. Is that how sysroot works? If it is similar that, autotools works fine in such environments (as did Imake). The Red Hat buildsystem (beehive) as well as other buildsystems such as mock, mach, etc. use an approach similar to this. I'm not too sure how this relates to X.Org architecture though. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkEntry problem
hi evert body i am making a GUI application with GTK+. i have a problem I have three GtkEntry widgets in a dialog box with one GtkButton(OK). i want to get the text written in the GtkEntry when the OK button is pressed through a Callback function. please tell me code for that Signal connectivity and also call back function prototype. bye _ Finding it difficult to find your life partner?Here is your solution http://www.bharatmatrimony.com/ http://creative.mediaturf.net/creatives/bm05/bm_msn_tagoffline.htm ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gnumeric on Scientific Linux
On Thu, 20 Oct 2005 22:49:51 -0400 Jody Goldberg [EMAIL PROTECTED] wrote: On Thu, Oct 20, 2005 at 10:37:12PM -0400, [EMAIL PROTECTED] wrote: trying to install gnumeric on a scientific linux 4.1 version. snip configure: error: Package requirements ( gtk+-2.0= 2.6.0 libglade-2.0= 2.3.6 libgnomeprint-2.2 = 2.8.2 libgnomeprintui-2.2 = 2.8.2 libart-2.0 = 2.3.11 ) were not met. Looks like it's called gtk2 I recently had occasion to build gnumeric (1.4.3) on a Solaris 7 box used as a spectrometer controller. The dependency tree is a bit daunting, but possible. Details available (I took careful notes) - mailto:[EMAIL PROTECTED] For me, the most difficult piece to resolve was a very old (ancient) X running on solaris, and the requirement for XFt and XRender. The newest versions of render support even old versions of X by drawing characters - which is pretty, but very slow, the point being that I'd gladly accept a little less look good for being able to bypass the advanced rendering and anti-alias, that requires me to build a font server and an entire set of fonts, and the entire tree to support such. I believe this is a GTK2 feature (which explains the cross post)(apologies) but I can't be the only person who has this particular difficulty with paleohardware. If my very expensive instrumentation would run on a more modern package, I'd dump it and it's associated problems in a nanosecond. -- Norm Reitzel (UTSA, Instrument Coordinator) http://mirror.cpsc.ucalgary.ca/mirror/scientificlinux.org/4x/i386/SL/RPMS/gtk2-2.4.13-14.i386.rpm which is not exactly modern. It seems like a Fedora/RH derivative which explains the lack of gnumeric. Leaving gnumeric out seems like an odd choice for a distribution targeting science. ___ gnumeric-list mailing list gnumeric-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnumeric-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for making the GtkFileChooser code asynchronous
From: James Henstridge [EMAIL PROTECTED] ... So if the two packages were not upgraded in lock-step, you'd just lose features rather than create instability. I guess its in the eye of the beholder, but this seems to be really splitting hairs. The concern is incompatibility, not instability. I think not being able to do something (supported) you could do before, classes as an incompatibility. - Joseph Kowalski ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GMainContext foo ...
Hi guys,
So - I've been trying to use the GMainContext to fix a rather tricky
issue in using unsafe single-threaded code accessed via ORBit2 from
multiple OO.o threads in a safe reliable way. This is somewhat
involved, for various reasons, but made particularly unpleasant due to 2
missing methods:
a) gboolean g_main_context_am_owner (void);
+ this would tell you if the current thread owns the
g_main_context. NB. this is subtly different from
something like:
if (g_main_context_acquire ()) {
g_main_context_release();
... I own it - horay ...
}
+ since that actually transiently takes ownership of
the thread but doesn't tell you if you (now) contine
to own it [ due to some (much) higher stack frame
having taken that lock ].
b) void g_main_context_acquire_no_really_do_it (void);
+ this cunning method - would be the analogue of
g_main_context_wait () - except instead of sitting
around hoping that the other thread doing the poll
will wake-up, it does a (safe) g_main_context_wakeup
with the relevant locks held;
+ currently it appears impossible/acutely-ugly to
get ownership of the GMainContext from another thread
if the main thread is in it's poll.
The basic reasoning here is that - ~all existing event-driven gtk+
code, typically happens from the default GMainContext, and/or at least
that provides a reasonable back-compatible way to create a backwards
compatible 'apartment' (by holding the GMainContext lock) to execute old
code in in-line.
Anyway, hopefully that's useful to someone, although I guess I'm not
optimistic about these ever getting in - simple as they are ;-)
If people are interested, I can knock up a simple patch too.
HTH,
Michael.
--
[EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Sun's fopen() fd limit of 256
I'm not sure if everyone is aware, but Sun has a long standing issue where fopen will fail if the # of open fds is greater than 0xff. The underlying reason is that they never updated their FILE struct to change the UNIX fd from an unsigned char. Only if you build your app as _LP64 does it finally use an int for the fd. In order to work around this bug we've maintained our own imitation f* API for reading/writing that does not have this 256 fd limit. Is there any benefit to providing a full GLib fopen/fread/fwrite/etc API which provides its own implementation if the system implementation has an fd limitation? The configure script could detect this and enable it if necessary. Just wondering if anyone else had run into this problem... Thanks, Andrew Paprocki Bloomberg LP Disclaimer: I'm a long time SunOS engineer and a short time GNOME lurker. The reason they never updated their FILE struct is that ol' binary compatibility constraint. I'm sure you are all aware that Sun goes to great lengths to keep existing binaries working. Right or wrong, that's the commitment we make to our customers. The core of the technical problem, is that getc/putc historically are macros. Every application that uses these has built in a hard dependency on the *exact* layout of the file structure (or at least the relevant sections of it). There also are some interesting details in the ABIs which apply constraints here. Depending on how one would try to finesse the implementation, one gets different exact set of restrictions, but they all boil down to being unable to mix legacy binaries (shared objects) with the newer implementation. Understanding this, it is possible to implement many flavors of 90% solutions (and please, lets not start proposing them to this broad alias). That brings up the question as to if a 90% solution is worthwhile. That is for you to judge, but be prepared to write a very long and twisted manual page as to when that solution will work for you and be prepared to see a number of unexpected failures because dependencies lurk where you least expect them. We (Sun) spent a lot of time looking for a 100% solution and spent a incredible amount of resources to even provide the 64-bit solutions (circa 1995-2000). I take solace in trend that 32-bit simply won't matter in a few years. Oh yea, this message reflects my personal views and not those of Sun Microsystems. - Joseph Kowalski ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.8.8. released
Hi, would be possible to have the file size displayed in the GtkFileChooser ? Thanks, -- Colossus Xarchiver, a GTK2 only archive manager - http://xarchiver.sourceforge.net Cpsed, a Linux OpenGL 3D scene editor - http://cpsed.sourceforge.net Mizio, a QT proxy hunter scanner tool - http://mizio.sourceforge.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Hardcore C++/unix/linux trading system development roles - top Wall Street firms
All full-time, permanent positions on various financial trading desks.Looking for core server-side C++ development skills on linux/unixplatforms. Highly challenging and rewarding work and you'll be compensated well. Financial experience is not required. If you'd like to learn more, please send me a note. -Patrick burke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
linking / performance / interposing detection ...
Hi guys, So - as part of my -Bdirect work - trying to detect genuine cases of interposing - I ran my simple perl script over all my gnome libraries: http://go-oo.org/ooo-build/bin/finterpose (for which I attach the gnome specific exclusions file [this incidentally shows lots of other bad behavior in Gnome ;-]): $ find /opt/gnome/lib -name '*.so' | finterpose ./gnome-exlusions I got some rather concerning output wrt. gtk+ theme engines eg. gtk-2.0/2.4.0/engines/libmetal.so exports 'parent_class' Also - the galloping cut/paste common in theme engine authorship seems to have resulted in at least these symbols being duplicated across tons of theme engines: option_menu_get_props is_combo_box find_combo_box_widget get_parent_window reverse_engineer_stepper_box theme_create_rc_style theme_pixbuf_render theme_pixbuf_set_border theme_pixbuf_set_filename theme_pixbuf_set_stretch theme_pixbuf_destroy theme_pixbuf_new theme_pixbuf_get_pixbuf is_combo_box_entry object_is_a combo_box_is_using_list theme_destroy_style theme_realize_style theme_destroy_rc_style theme_unrealize_style theme_set_background theme_parse_rc_style theme_merge_rc_style theme_duplicate_style theme_rc_style_to_style theme_init theme_exit old_vscrollbar_realize old_hscrollbar_slider_update old_vscrollbar_slider_update old_hscrollbar_realize old_hpaned_realize old_vpaned_realize sanitize_parameters is_in_combo_box is_combo is_toolbar_item is_panel_widget_item old_scrolled_window_map old_scrolled_window_size_allocate step_vscrollbar_parent_set So - I guess, this shouldn't be -that- concerning in some ways - but looking further - it *seems* that the loading of themes is done in such a way as to include them in the global symbol search path: gtk/gtkthemes.c: engine-library = g_module_open (engine_path, 0); Q1: is it possible to have 2 gtk themes loaded concurrently ? and if so - why don't we see hideous problems wrt. 'theme_init' being looked up incorrectly in the 2nd theme ? Q2: -why- are we routinely loading all these nice separated plugin libraries into the global symbol search scope ? $ LD_BINDINGS=symbol gtk-demo on my machine shows: 16350: symbol=__gmon_start__; lookup in file=.../gtk-2.0/2.4.0/loaders/libpixbufloader-gif.so 16350: symbol=__gmon_start__; lookup in file=.../gtk-2.0/2.4.0/engines/libindustrial.so 16350: symbol=__gmon_start__; lookup in file=.../pango/1.4.0/modules/pango-basic-fc.so Ok - so they're at the end of the list here it's true - so the effect for gtk-demo is small; but it's easy to imagine loading other libraries, plugins / components etc. after that [ eg. the file-selector + deps ? ;-] and them having to search a number of extra, pointless image loader / pango / theme engine bits per-symbol without any real need for that ? I guess the fix would be to use G_MODULE_BIND_LOCAL ( at least - assuming that does the right thing ) - in all the g_module_opens - which would surely be a fairly painless change / patch ? HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot # glib / gtk modules: g_module_check_init gtk_module_init im_module_init im_module_create im_module_list im_module_exit # gconf gconf_backend_get_vtable # ORBit2 / bonobo orbit_imodule_data Bonobo_Plugin_info # gnome-print gnome_print__transport_get_type gnome_print__filter_get_type gpa_module_init # gnome-vfs vfs_module_init vfs_module_shutdown # glade glade_module_register_widgets # gstreamer gst_plugin_desc # Nautilus nst_init_plugin nautilus_module_shutdown nautilus_module_list_types nautilus_module_initialize # gimp gimp_module_query gimp_module_register # xchat modules xchat_plugin_init xchat_plugin_deinit xchat_plugin_get_info # epiphany register_module # gaim gaim_init_plugin # planner module_init module_exit module_new # a11y modules gnome_accessibility_module_shutdown gnome_accessibility_module_init ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: how can include just glib
Ok good question I know how to include the library, but HOW can I init the library. If you use gtk and gtk_init, it will init GLib too then, how do I do that?2005/12/13, Fernando Apesteguía [EMAIL PROTECTED] :Did you try to make this?#include glib.hAnd then link with -lglib-2.0 (link against your glib version)Best regards-- Forwarded message --From: Yiannis [EMAIL PROTECTED]Date: 13-dic-2005 16:08 Subject: how can include just glibTo: gtk-app-devel-list@gnome.orgHi,I would like to use just glib in my programming without the header files of gtk How is that possible?Cheers. Yiannis___gtk-app-devel-list mailing listgtk-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.orghttp://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Trabajar, la mejor arma para tu superación ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
build gdk on cairo-xcb
hi, everybody i want to build gtk+ with xcb instead of xlib , here are my steps: step 1: build cairo-1.0.2 , i use --enable-xcb --disable-xlib as the configure option. step 2: build pango-1.10.0 , then i get libpangocairo,etc. step 3: build gtk+-2.8.9 , but i met the following error: In file included from gdkdrawable-x11.c:32: /Helium/host/include/cairo/cairo-xlib.h:76:3: #error Cairo was not compiled with support for the xlib backend. i found that gdkdrawable-x11.c include cairo-xlib.h only. i think there should be conditional compile, just include cairo-xlib.h or cairo-xcb.h . is there gdkdrawable-x11.c that use cairo-xcb yet ? -jianjun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ printing dialog highlevel thoughts
Alexander Larsson wrote: (cc:ing some people who I think might be interested in this) I've just started looking at doing a printing dialog for Gtk+ 2.10. For some background thoughts from owen, see: http://mail.gnome.org/archives/gtk-devel-list/2005-October/msg00024.html FWIW, both Windows and MacOS X provide APIs for accessing the list of available printers, etc., and the CUPS API is also available on MacOS X. WRT Linux printing, CUPS is pretty much ubiquitous, and failing that you can standardize on PAPI (the SourceForge library apparently supports CUPS, LPR, and Solaris lp - check with Norm Jacobs for details...) I've started studying various platform APIs and UIs, cups, PPDs, etc, preparing for this. To compare various platform and application printing dialogs I have put together a set of screenshots from Linux/OSX/Windows at: http://people.redhat.com/alexl/print_dialogs/ Thanks for the extensive set of screenshots! ... * Printing photos This is (these days) a pretty common task, but substantially different from what the traditional print dialogs are made to support. We could make this a standard type of dialog simplifying such printing. See the e.g. the easy print dialog in OSX in the screenshots above. This type of printing functionality is also useful for a lot more than just image printing. Also, it would be really nice to allow any app to print N-up as well as poster printing (scaling and printing on multiple pages...) * Using the Gtk+ dialog as a native print dialog For instance, OOo could use the Gtk+ print dialog for its printing UI on Linux/Unix, but then not use the Gtk+ print system (cairo) to print, instead going directly to the lowlevel printing system and use its own postscript generation. Yes, there are a bunch of applications that want to do this, however in most cases you'll be better off sticking with the standard print path as generating good PS/PDF output is not trivial. I'd argue that the more we can do to improve the low-level print/file generation APIs (i.e. Cairo or whatever), the more likely it will be that apps will not need to bypass the standard paths. Look at what Apple has done with Quartz and the Print Manager APIs - by the sounds of things, Adobe will (finally) be moving away from using the old Carbon print APIs, and their apps use just about every trick in the book when printing... * Printing without a UI Its very useful for applications to be able to print without opening a dialog. For instance by passing --print file on the command line. In this case it would be nice if the Gtk+ printing system supported a headless mode that didn't need a connection to the Display, but still allowed one to use the same printing code. This is where a good low-level print API comes in handy... One important question that owen brough up is the Can we/can we not use the native UI?. If we go with native dialogs we loose a certain amount of customizability, we get a bit more non-standard APIs (i.e. we're unable to use GtkDialog derived objects), and we're a bit limited in what the dialogs can do (least-common denominator of features, although we might be able to do better with some work). For Windows, at least, you'll need to use the native interface to select printer driver options/properties. This is because Microsoft, in their infinite wisdom, chose to make all printer driver options part of private device mode data structures which are passed around, and the only way to initialize these data structures is to run printer driver code on the system... My opinion is that we should go with native dialogs. Printing dialogs are already confusing enough that having to learn a totally new one is a pain, and its probably gonna be very hard to make a print dialog that works right on Windows, because I don't think all the required APIs are availible. Furthermore, you'd loose driver-specific additions to the printer dialogs that are availible in Windows/OSX. It makes sense to use the OS-supplied print dialogs when they are available and provide sufficient functionality, however there *is* no standard dialog on Linux (at least not yet :) so there is still the issue of coming up with a toolkit-neutral interface that can be used by all... I've been talking to the Tor on Win32 and Andersca on OSX, and both think it should be possible (but not tested yet) to embedd gtk+ widgets into a native dialog, so if we're lucky we can allow some generic way of adding custom widgets to the dialog. (Given the APIs on OSX and Win32 this will likely be in the form of an extra tab page.) ... Right, we've looked at doing something similar with FLTK as well... The same techniques for embedding windows in browsers, etc. will work with the print dialogs. -- __ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Publishing Software
Re: Glib 2.10 / Pango 1.? for GNOME 2.14?
Il giorno mer, 18/01/2006 alle 10.21 -0600, Federico Mena Quintero ha scritto: Sorry that I dropped the ball on this, and haven't followed all the discussion. Other than Pango optimizations and and GSlice in Glib, is there a compelling reason to use the new Glib/Pango in GNOME 2.14? Unicode 4.1 ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ printing dialog highlevel thoughts
Alexander Larsson wrote: On Wed, 2006-01-18 at 19:39 -0500, Michael Sweet wrote: Alexander Larsson wrote: (cc:ing some people who I think might be interested in this) I've just started looking at doing a printing dialog for Gtk+ 2.10. For some background thoughts from owen, see: http://mail.gnome.org/archives/gtk-devel-list/2005-October/msg00024.html FWIW, both Windows and MacOS X provide APIs for accessing the list of available printers, etc., and the CUPS API is also available on MacOS X. WRT Linux printing, CUPS is pretty much ubiquitous, and failing that you can standardize on PAPI (the SourceForge library apparently supports CUPS, LPR, and Solaris lp - check with Norm Jacobs for details...) I think relying on CUPS might be good enough. Opinions on this? Does e.g. solaris ship CUPS? It is provided on the Solaris companion CD, but not installed by default. * Printing photos This is (these days) a pretty common task, but substantially different from what the traditional print dialogs are made to support. We could make this a standard type of dialog simplifying such printing. See the e.g. the easy print dialog in OSX in the screenshots above. This type of printing functionality is also useful for a lot more than just image printing. Also, it would be really nice to allow any app to print N-up as well as poster printing (scaling and printing on multiple pages...) With a callback-driven printing mainloop i think this is pretty easy to do. The mainloop would just set the CTM and clip rect before calling the page rendering callbacks (multiple callbacks per physical page for N-up, and call the same callback for multiple physical pages for poster printing). Right. Yes, there are a bunch of applications that want to do this, however in most cases you'll be better off sticking with the standard print path as generating good PS/PDF output is not trivial. I'd argue that the more we can do to improve the low-level print/file generation APIs (i.e. Cairo or whatever), the more likely it will be that apps will not need to bypass the standard paths. Look at what Apple has done with Quartz and the Print Manager APIs - by the sounds of things, Adobe will (finally) be moving away from using the old Carbon print APIs, and their apps use just about every trick in the book when printing... I think this is an fine long term goal. However we have to recognise the fact that there are currently apps (like OOo) that won't do this and we have to support these apps anyway. Right, you'll always have a back door for submitting custom output, just make sure that app developers don't need to do it... :) It makes sense to use the OS-supplied print dialogs when they are available and provide sufficient functionality, however there *is* no standard dialog on Linux (at least not yet :) so there is still the issue of coming up with a toolkit-neutral interface that can be used by all... Since this is the discussion of the gtk+ print dialog addition I think its fair to say that the linux/unix-specific dialog will be written in Gtk+. A toolkit-neutral dialog seems very hard to make from a technical standpoint, and its gonna have integration issues with all toolkits. Not specifically the dialog itself (although it would be nice to offer either a standalone command a la kdeprint/gtklp or a simple C API to hook into it), but definitely a standard low-level API to hook into the print system (CUPS, PAPI, whatever) so that all toolkits can get their printer info from the same place... Right, we've looked at doing something similar with FLTK as well... The same techniques for embedding windows in browsers, etc. will work with the print dialogs. Did you get any results from this? I.E. do you have some working code. I think there are several implementations on the links page: http://www.fltk.org/links.php I'll see if I can come up with some specific links... -- __ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Publishing Softwarehttp://www.easysw.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Mail moderator queue
Hey, The mail queue hadn't been flushed since August, so we'd built up a healthy backlog of messages (and unhealthy backlog of spam.) I went ahead and moderated it. A bunch of random messages will probably appear soon. Also, I signed this list up for the moderator project, so hopefully it won't happen again. Thanks, -Jonathan signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib 2.10 / Pango 1.? for GNOME 2.14?
On Thu, 2006-01-19 at 09:13 -0500, Behdad Esfahbod wrote: I think a better way to rephrase Federico's question is: should the floating stuff be rolled back? I think that was discussed and closed already. So we have a glib release that we want to not use?! The question is really about glib now. Pango is using some new stuff in latest glib, includeing g_slice, like many other modules do already.. Thanks to everyone for their replies. There's indeed a bunch of interesting stuff using the new APIs. My remaining gripes are these: - Has anyone confirmed that floating references are not an ABI break? You can test this by installing Glib HEAD on top of a GNOME 2.12 installation, and seeing if anything breaks. - (In reply to Kjartan): There is no way to disable GSlice to make it just use malloc() for the requested blocks. This prevents us from using valgrind to find leaks and memory corruption. This is also a regression, since this debugging functionality was available with GMemChunk. Fixing the GSlice issue is an afternoon's work. Here is a detailed description of the work that is needed: http://mail.gnome.org/archives/gtk-devel-list/2005-December/msg00149.html (see also Matthias's and Tim's replies). Any takers? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtkspell (was Re: Announcing: Project Ridley)
On 8/27/05, Chipzz [EMAIL PROTECTED] wrote: I'm not a Gtk+ developer, but I think one of the criteria for being considered is: doesn't introduce a new library dependency, or maybe it can, if it really makes sense. Gtk+ depending on a spell checking library hardly makes sense, however. I would envision a solution having two parts here: - some framework in GtkEntry/GtkTextView to support spellchecking - a module which makes use of the framework. The module could use Enchant, GtkSpell or any other spell-checking library - the module could be loaded desktop-wide, by using the gtk-modules setting that was introduced for this purpose a while ago. Maybe thats a totally wrong approach, I haven't thought too long about it. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtkspell (was Re: Announcing: Project Ridley)
On 1/19/06, Matthias Clasen [EMAIL PROTECTED] wrote: On 8/27/05, Chipzz [EMAIL PROTECTED] wrote: I'm not a Gtk+ developer, but I think one of the criteria for being considered is: doesn't introduce a new library dependency, or maybe it can, if it really makes sense. Gtk+ depending on a spell checking library hardly makes sense, however. I would envision a solution having two parts here: - some framework in GtkEntry/GtkTextView to support spellchecking - a module which makes use of the framework. The module could use Enchant, GtkSpell or any other spell-checking library - the module could be loaded desktop-wide, by using the gtk-modules setting that was introduced for this purpose a while ago. Enchant has been API/ABI stable for a while now, so I wouldn't mind proposing it for inclusion to the platform at some future point (or better still, free desktop). Chris Hammond's libsexy has a spell checking enabled GtkEntry subclass that depends on Enchant. It dlopen()'s the .so and looks up the functions by name rather than linking against it explicitly. If the module isn't found, spell checking is disabled. This might be something of a compromise solution, since it gives consumers a soft dependency on a spell checking lib rather than a hard dependency. Best, Dom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ printing dialog highlevel thoughts
On Wed, 2006-01-18 at 20:07 +0100, Alexander Larsson wrote: Another important feature that the generic API has to support is some form of printing feedback (spinning icon while printing) and job cancellation support. We do this in Fedora/RHEL right now with D-Bus patches to CUPS which polls job states and broadcasts signals for local printers. For remote printers eggcups polls directly. It is not the best. CUPS 1.2 has notification support where we can write a notifier to propagate the events over D-Bus. We might need to write a remote notifier also. Does CUPS 1.2 have notifiers that will propagate to a local cups notifier? Eggcups right now handles job cancellation and showing state changes. The biggest problem with relying on 1.2 is that it is not out yet. Michael, excuse me if you answered this in another e-mail, but do you know the time frame? I'm going to get the sources and play around with it a bit. Perhaps I can take what we have got and move the API closer to what we will have in the future. -- John (J5) Palmieri [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: how can include just glib
Hi, On Tue, 13 Dec 2005 16:36:44 +0100, Daniel Espinosa wrote: ... but HOW can I init the library. If you use gtk and gtk_init, it will init GLib too then, how do I do that? What specific problem do you have? glib - it does not need any init gobject - it needs g_type_init() gthread - it needs g_thread_init(NULL) (although gthread initialization is more specific) gmodule - it does not need any init Regards, Lace ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ printing dialog highlevel thoughts
This is a really nice write up, Alex! I'm replying to selected parts. On Wed, 2006-01-18 at 20:07 +0100, Alexander Larsson wrote: (cc:ing some people who I think might be interested in this) I've just started looking at doing a printing dialog for Gtk+ 2.10. For some background thoughts from owen, see: http://mail.gnome.org/archives/gtk-devel-list/2005-October/msg00024.html I've started studying various platform APIs and UIs, cups, PPDs, etc, preparing for this. To compare various platform and application printing dialogs I have put together a set of screenshots from Linux/OSX/Windows at: http://people.redhat.com/alexl/print_dialogs/ This is a great comparison. One important question that owen brough up is the Can we/can we not use the native UI?. If we go with native dialogs we loose a certain amount of customizability, we get a bit more non-standard APIs (i.e. we're unable to use GtkDialog derived objects), and we're a bit limited in what the dialogs can do (least-common denominator of features, although we might be able to do better with some work). My opinion is that we should go with native dialogs. Printing dialogs are already confusing enough that having to learn a totally new one is a pain, and its probably gonna be very hard to make a print dialog that works right on Windows, because I don't think all the required APIs are availible. Furthermore, you'd loose driver-specific additions to the printer dialogs that are availible in Windows/OSX. At the Boston summit, we came to the opposite conclusion. We looked at a random windows installation, and it seemed like every application had a different print dialog. Even on OS/X, there was a lot of variety. If we did go with the 'native' dialog, it wasn't empirically clear which native dialog that would be. It may be easier anyway to use it, but consistency is a bad argument here. The driver-specific options is a better argument for that, though. I've been talking to the Tor on Win32 and Andersca on OSX, and both think it should be possible (but not tested yet) to embedd gtk+ widgets into a native dialog, so if we're lucky we can allow some generic way of adding custom widgets to the dialog. (Given the APIs on OSX and Win32 this will likely be in the form of an extra tab page.) If there is some simple common feature we want to support that is missing on a particular platform we could customize the native dialog from gtk itself so that all gtk apps would use the same ui for it, and its availible on all platforms. It might be wise to allow some amount of access to the platform-specific objects so that advanced applications can do more advanced customization using #ifdef. Sounds very reasonable The print dialog implementation has two parts. First the generic portable API with implementations for the platform native dialogs, then the native dialog for Unix. In order to support the Using the Gtk+ dialog as a native print dialog use-case we probably need to expose this as a platform-specific api, with accessors similar to the ones we have for accessing e.g. the win32 print dialog object. So typical code would be something like: #ifdef WIN32 dialog = gtk_win32_print_dialog_new (); if (gtk_win32_print_dialog_run (dialog) == GTK_RESPONSE_OK) ...; #else dialog = gtk_print_dialog_new(); if (gtk_dialog_run (dialog) == GTK_RESPONSE_OK) ...; #endif Would we expect all the various gtk_print_dialog_* functions to be available? For the native functions, or will every app running on Win32 have to special case printing? I think we should have a Page Setup dialog, supporting the native dialogs of the platforms. While using the native dialog here is less important, since it does less magic than the print dialog, and there is already a considerable amount of variation in this dialog I think its important that at least simple print applications look normal on the platform. Agreed. snip I think the general print model should go something like: * create a print job * set settings on it (page settings etc) * call the print method, bringing up the print dialog * user sets options in dialog, presses print * internally we get the underlying native object to print to (hDC, NSView, cups printer + PPD) * internally we create a cairo context for the native object and pass it to the app * the app draws stuff to the cairo context, possibly using some furter information from the print dialog result The last drawing part can be done in several ways. Either procedurally (just draw all the pages in order), or with some form of callback driven system. The callbacks could either always be called in page incremental order, or it could be random access given a page number as argument. I think the callback driven, random access model is the best. It allows us to handle things like nr of copies and collation perfectly invisible from the app. It does put some higher demands on simpler
