RE: How to change color of GtkCellRendererProgress ?
Sorry this is a bad answer. Of course you can do this!! and that is no reason not to use GTK. You can use the themes, or if you need individual progress bars to be different colors, you can easily derive a GtkCellRenderProgressFooBar class from the GtkCellRendererProgress, which does this, and if it is useful enough, maybe the rest of us will use it in our app, and submit it for inclusion. I'm surprised it is not in the default functionality, but there are a lot of ways you can do this. From: kcc1...@gmail.com Date: Mon, 2 Aug 2010 10:21:31 +0800 Subject: Re: How to change color of GtkCellRendererProgress ? To: jardas...@gmail.com CC: gtk-app-devel-list@gnome.org On Mon, Aug 2, 2010 at 2:46 AM, Jaroslav Šmíd jardas...@gmail.com wrote: You can't. The only way to change this is to modify theme you use. That's bad news to me. I were planned to use it for a simple histogram application but color is required feature ... Thanks anyway. Regards KC On Sat, Jul 31, 2010 at 6:33 AM, Kuang-Chun Cheng kcch...@linuxdaq-labs.com wrote: Hi, As subject said, how to change color of GtkCellRendererProgress ? Either color of text or bar is OK. This looks like a simple question, but I can't find anything from Google yet. Thanks a lot. Regards, KC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Jaroslav Šmíd ___ 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 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: Multi-platform dbus (was: Ige-mac-integration: New version with Cocoa interface available)
Sorry for my naivete
But I have been building some of our application tool sets in native Cocoa (the
printing industry is exclusively MAC, with little room for anything else).
The question being, in the standard Cocoa application framework you never
actually derive the NSApplication class, but instead you derive the
NSApplicationDelegate. Would this not be more appropriate for this discussion.
It receive all the signals for each interface object whos IBoutlet is set to
this class, and all the functionality for the toolbar, menu, etc, is exposed in
it.
IE this class actually receives the signal for the NSSearchField object, and
process it. So should GTKApplication.c not really be GTKApplicationDelegate.c,
or perhaps both.
Last I recall of the MFC, there was something similar where you had a
CCmdTarget which did a lot of what I guess GTKApplication.C is todo, but seems
more inline with NSApplicationDelegate than NSApplication.
I've noticed a lot of stuff like GTKTreeView implement its own displays, why is
it not derived from NSTableView using NSDataSource for GTKTreeStore and
GTKListStore? Or is the point to also make it all look alike?
-- MY APP DELIGATIONS
@interface isiod2AppDelegate : NSObject NSApplicationDelegate {
/*Views */
NSWindow *window;
AnalyzerView *view;
SimpleCView *scView;
/* Fields */
NSSearchField *searchField;
NSTextField *startDate;
NSTextField * endDate;
/* Tables */
NSTableView *shippingTable;
NSTableView *receivingTable;
NSTableView *batchesTable;
NSTableView *usageTable;
/* Data sources */
isilistDataSource *shippingDS;
isilistDataSource *receivingDS;
isilistDataSource *batchesDS;
isilistDataSource *usageDS;
/* Internal objects */
IsiComponent *component;
IsiDatabase *db;
}
/* Views */
@property (assign) IBOutlet NSWindow *window;
@property (assign) IBOutlet AnalyzerView *view;
@property (assign) IBOutlet SimpleCView *scView;
/* Fields */
@property (assign) IBOutlet NSSearchField *searchField;
@property (assign) IBOutlet NSTextField * startDate;
@property (assign) IBOutlet NSTextField * endDate;
/* Tables */
@property (assign) IBOutlet NSTableView *shippingTable;
@property (assign) IBOutlet NSTableView *receivingTable;
@property (assign) IBOutlet NSTableView *batchesTable;
@property (assign) IBOutlet NSTableView *usageTable;
/* Actions */
- (IBAction)filterSearch:(id)sender;
@end
Subject: Re: Multi-platform dbus (was: Ige-mac-integration: New version with
Cocoa interface available)
From: jra...@ceridwen.us
Date: Tue, 18 May 2010 14:10:22 -0700
To: p...@linuxaudiosystems.com
CC: gtk-devel-l...@gnome.org
On May 18, 2010, at 1:36 PM, Paul Davis wrote:
On Tue, May 18, 2010 at 4:12 PM, John Ralls jra...@ceridwen.us wrote:
Sure. But dbus provides services which are provided by notifications and
AppleEvents on OSX. If a supposedly cross-platform application supports
only the dbus way, it turns out to be pretty autistic on OSX. I don't think
that it's all that common for OSX users (aside from the few Fink and
MacPorts users who are trying to replicate an entire Linux environement) to
run more than one or two dbus-using apps, and they aren't able to
communicate with other OSX application or OSX itself unless those channels
are separately implemented.
So maybe g_dbus isn't the right place for the abstraction layer; it could
be one of the implementation layers.
i think that is precisely what is being proposed:
GApplication/GtkApplication as the abstaction that covers notifications
etc, and an implementation for a given platform. the linux/X11/FD.org one
would use DBus. apps that choose to use DBus directly will be assumed to
want something specific that DBus offers, and not a generic
platform-agnostic application abstraction.
OK.
I don't think that GApplication is a good name for it, though. The fact that
some notifications (became active, quit, etc.) are directed at the
application object doesn't mean that all of them should be.
Regards,
John Ralls
___
gtk-devel-list mailing list
gtk-devel-l...@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
_
The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: different data types between clist and mysql.
Ran into same problem.
I use a structure like
_IsiField {
int type,
int pos,
int
}
Then create my own list with
_IsiList {
GList Fields;
GList rows;
}
Every time retrieve a set of values, I have a routing which sets type to a
G_TYPE, which corresponds to the MYSQL_TYPE
Here is what I do:
GList *
isi_database_fetch_fields(IsiDatabase *self)
{
MYSQL_FIELD *field;
IsiFields *l;
GList *gl = NULL;
guint column = 0;
/* Sanity Check */
g_return_val_if_fail(self != NULL, NULL);
g_return_val_if_fail(self-priv != NULL, NULL);
g_return_val_if_fail(self-priv-dispose_has_run != TRUE, NULL);
g_return_val_if_fail(self-priv-res != NULL, NULL);
/* Rewind the feild set */
mysql_field_seek(self-priv-res,0L);
while((field = mysql_fetch_field(self-priv-res)))
{
/* Initialize a new IsiFields structure */
//l = (IsiFields*) g_new0(IsiFields, 1);
l = g_new0(IsiFields, 1);
/* Set the values */
l-alias = g_strdup(field-name);
l-name = g_strdup(field-org_name);
l-length = field-length;
/* always make fields visable */
l-hidden = FALSE;
l-sortable = FALSE;
l-pos = column++;
switch (field-type){
/* Integer types */
case MYSQL_TYPE_TINY:
case MYSQL_TYPE_SHORT:
case MYSQL_TYPE_INT24:
/* Check for signage */
if (field-flags UNSIGNED_FLAG)
l-type = G_TYPE_UINT;
else
l-type = G_TYPE_INT;
break;
/* Long types */
case MYSQL_TYPE_LONG:
case MYSQL_TYPE_LONGLONG:
/* Check for signage */
if (field-flags UNSIGNED_FLAG)
l-type = G_TYPE_ULONG;
else
l-type = G_TYPE_LONG;
break;
/* Decimal types */
case MYSQL_TYPE_DECIMAL:
case MYSQL_TYPE_NEWDECIMAL:
case MYSQL_TYPE_FLOAT:
case MYSQL_TYPE_DOUBLE:
l-type = G_TYPE_DOUBLE;
break;
/* Bit types */
case MYSQL_TYPE_BIT:
l-type = G_TYPE_BOOLEAN;
break;
/* ENUM types */
case MYSQL_TYPE_ENUM:
l-type = G_TYPE_ENUM;
break;
/* All other types */
default:
case MYSQL_TYPE_STRING:
case MYSQL_TYPE_VAR_STRING:
case MYSQL_TYPE_BLOB:
case MYSQL_TYPE_SET:
case MYSQL_TYPE_TIMESTAMP:
case MYSQL_TYPE_DATE:
case MYSQL_TYPE_TIME:
case MYSQL_TYPE_DATETIME:
case MYSQL_TYPE_YEAR:
case MYSQL_TYPE_GEOMETRY:
case MYSQL_TYPE_NULL:
if(l-length = 1){
l-type = G_TYPE_CHAR;
}else{
l-type = G_TYPE_STRING;
}
break;
}
/*DEBUG*/
//g_print(%s %d %d \n, l-alias,l-type,l-length);
/* Save pointer to list */
gl = g_list_append(gl,(gpointer)l);
}
return gl;}
now convert the row data to a GList and you have two GLists in your one lists,
one with the field header info, the other with the data.
and create the liststore like this:
GtkTreeModel *
isi_display_liststore_create(IsiDisplay *self, GList *fields)
{
guint num_fields, i;
IsiFields *l;
GtkTreeModel *model;
GType *types;
guint search_col_adj = 0;
/* Sanity Check */
g_return_val_if_fail(self != NULL, NULL);
g_return_val_if_fail(self-priv != NULL, NULL);
g_return_val_if_fail(self-priv-dispose_has_run != TRUE, NULL);
/* Get the number of fields */
if(fields != NULL){
num_fields = g_list_length(fields);
/* Initialize values based on number of columns */
types = (GType*) g_new0( GType, num_fields);
for(i=0;inum_fields;i++){
l = (IsiFields*)g_list_nth_data(fields,i);
types[i] = l-type;
}
/* create the model store for data input */
model = (GtkTreeModel*) gtk_list_store_newv(num_fields,types);
g_free(types);
for(i=0;inum_fields;i++){
l = (IsiFields*)g_list_nth_data(fields,i);
/* Setup sorting functions for the modle */
switch(l-type){
case G_TYPE_INT:
l-sortable=TRUE;
gtk_tree_sortable_set_sort_func(GTK_TREE_SORTABLE(model),
l-pos, sort_by_int,(gpointer) l-pos, NULL);
break;
case G_TYPE_UINT:
l-sortable=TRUE;
gtk_tree_sortable_set_sort_func(GTK_TREE_SORTABLE(model),
l-pos, sort_by_uint,(gpointer) l-pos, NULL);
break;
case G_TYPE_LONG:
l-sortable=TRUE;
gtk_tree_sortable_set_sort_func(GTK_TREE_SORTABLE(model),
l-pos, sort_by_long,(gpointer) l-pos, NULL);
break;
case G_TYPE_ULONG:
l-sortable=TRUE;
RE: GdkOffscreenWindow and texture_from_pixmap extension
Juan, Let me know if you find a good way to do this with GtkGLExt, it is something I need to do on the OS X platform. I think this will help you, here is where I first came across on the apple devnet: http://developer.apple.com/mac/library/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_offscreen/opengl_offscreen.html#//apple_ref/doc/uid/TP40001987-CH403-SW2 and here is the actual opengl reference to it: http://www.opengl.org/registry/specs/EXT/framebuffer_object.txt You can use OpenGL Extensions to create buffers (original was only for texture maps apparently), render to them, and place them in scene as texture, or pictures, or even video, the best thing is there is a whole set of utils to take the buffer, and render directly to objects, and can be done so in a single context, of your choosing. This is how OS X does its fancy iChat AV In general rendering to offscreen will be much slower then rendering directly to a video framebuffer. EMAILING FOR THE GREATER GOOD Join me Date: Thu, 1 Apr 2010 20:25:11 -0700 Subject: GdkOffscreenWindow and texture_from_pixmap extension From: juanpablouga...@gmail.com To: gtk-app-devel-list@gnome.org Hello everyone. I want to do some OpenGL widget compositing using GtkGLExt and GdkOffscreenWindow. I implemented a offscreen widget as the ones in gtk-demo to be able to use the offscreen GdkPixmap as the source for a texture. But I am having some problems while trying to bind the GdkPixmap to the texture So does anyone know how to ge a Pixmap, as returned by XcompositeNameWindowPixmap(), from a GdkOffscreenWindow in order to use it in glxCreatePixmap()? thanks Juan Pablo ___ 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
RE: displaying a number on screen
Try retreiving the cairo context for the widget you want to draw in and try this: /* Create the default Layout */ layout = pango_cairo_create_layout(cr); /* Atach the font descriptor */ font_description = pango_font_description_new(); /* Setup Fonts and color and other layout attributes*/ pango_font_description_set_family(font_description,Helvetica); cairo_set_source_rgba(cr, 0.3, 0.3, 0.3, 1.0); pango_font_description_set_absolute_size(font_description, 0.28 * PANGO_SCALE); pango_font_description_set_weight(font_description,PANGO_WEIGHT_BOLD); pango_layout_set_font_description(layout,font_description); gchar * l1 = g_strdup_printf(%s-%d,label-aid,label-nid); cairo_move_to(cr, 0.05 * xmultip, 0.00 * ymultip); pango_layout_set_text(layout,l1,-1); pango_cairo_show_layout(cr,layout); You can also use pango_layout_set_markup(layout,l1,-1); using Pango markup to change text style. EMAILING FOR THE GREATER GOOD Join me Date: Sat, 27 Mar 2010 23:58:15 +0530 Subject: displaying a number on screen From: rao.nisc...@gmail.com To: gtk-app-devel-list@gnome.org Hi, I am sorry if this is not the right mailing list. For given x and y co-ordinates is it possible to display a particular number at that position? or in other words, is it possible to paint a number or character on the screen at a given point? Thanks in advance. -- regards, Nischal E Rao blogs.sun.com/nischal Join RVCE OSUM at http://osum.sun.com/group/rvceosum ___ 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
RE: how to draw something on GtkDrawingArea when I click a button?
As a matter of fact. I would suggest using Cairo. Which will allow you to then
draw in any context (IE Printer, PDF, etc...)
/* Local Variables */
cairo_t *cr;/* Rendering context derived from widget */
/* Get the context to which we need to draw */
cr = gdk_cairo_create(widget-window);
/* Printer context would be:
cr = gtk_print_context_get_cairo_context(context)
where context is a GtkPrinterContext* */
/* If we have a valid context draw valid object */
if (cr != NULL){
/* Boarder rectangle */
cairo_rectangle(cr, 0.00, 0.00, 20.0 , 40.0 );
cairo_stroke(cr);
cairo_set_line_width(cr,line_width / 60);
/* Virtical Seporation lines */
cairo_move_to(cr, 20.0 , 40.0 );
cairo_line_to(cr, 40.0, 40.0);
cairo_stroke(cr);
/* Distroy the context we created */
cairo_destroy(cr);
}
EMAILING FOR THE GREATER GOOD
Join me
Subject: Re: how to draw something on GtkDrawingArea when I click a button?
From: csaave...@gnome.org
To: gtk-app-devel-list@gnome.org
Date: Fri, 19 Mar 2010 08:46:33 +0200
El vie, 19-03-2010 a las 13:34 +0800, Tolic Ma escribió:
Hi,everyone!
I want to draw something on GtkDrawingArea when I click a GtkButton,but I
don't know how to do this...
this is my code(it doesn't work...):
*void click_button(void){
gdk_draw_line(drawing_area,drawing_area-style-white_gc,x,y,width+x,height+y);
}
You shouldn't draw directly in your callback for the button. Instead,
you should call gtk_widget_queue_draw() to tell GTK+ to schedule a paint
of the widget.
How will the widget be painted? GTK+ will tell your code that the widget
needs to be painted by emitting the GtkWidget::expose-event signal.
Then, you should connect to that signal and paint in your callback.
Last but no least, don't forget to paint to the GdkWindow of the drawing
area, since that's the drawable.
More or less (untested code, just for clarity):
*void
click_button(GtkButton *button, gpointer data)
{
button_clicked = TRUE;
gtk_widget_queue_draw (drawing_area);
...
}
gboolean
expose_drawing_area (GtkWidget *area,
GdkExposureEvent *event,
gpointer data)
{
...
if (button_clicked) {
gdk_draw_line(drawing_area-window,
drawing_area-style-white_gc,x,y,width+x,height+y);
}
...
}
int main(int argc,char *argv[]){
...
g_signal_connect(button,clicked,G_CALLBACK(click_button),NULL);
g_signal_connect(drawing_area,expose-event,G_CALLBACK(expose_drawing_area),NULL);
...
}
Claudio
--
Claudio Saavedra csaave...@gnome.org
___
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
RE: gtk+-2.18, win32, and OpenGL
FYI --- The same thing happens on the OS X version using the Native GTK (NON X Windows). No mater where the widget. It always takes up the entire windows, and does not respond to mouse input. Could it be that the issue is not platform specific? EMAILING FOR THE GREATER GOOD Join me Subject: Re: gtk+-2.18, win32, and OpenGL From: al...@redhat.com To: t.ev...@aranz.com Date: Mon, 15 Feb 2010 10:21:01 +0100 CC: gtk-devel-l...@gnome.org On Mon, 2010-02-15 at 12:07 +1300, Tim Evans wrote: Previous with GTK+ 2.14 I had some custom code that would let me draw with OpenGL into a widget under win32. After updating GTK+ 2.18 this code doesn't work properly any more, it turns the entire toplevel window into an OpenGL area instead. I've gotten part way to having it work by calling gdk_window_ensure_native() on the window behind my OpenGL area widget, but some things are still broken: Hmmm, ideally that should not be needed. Its not on the X11 version of client side windows. There the gdk_x11_drawable_get_xid() call will automatically create a native window if you call it on a client-side window. Win32 should do the same. However, the win32 port of client side windows does not really seem fully done. Unfortunately I don't personally have time to work on it at the moment. 1. I've found I need to call SetWindowPos manually to resize the native window when the widget is allocated. Is this the expected behaviour? No, this is likely another bug in win32 csw support. 2. Mouse events seem to be screwed up. After clicking on my OpenGL area widget, other widgets will not receive enter-notify-event until I click again outside the widget, making buttons and other widgets not work. Is there a way to fix this? same here. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a world-famous shark-wrestling househusband on his last day in the job. She's a bloodthirsty punk bounty hunter from a different time and place. They fight crime! ___ gtk-devel-list mailing list gtk-devel-l...@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: How I can do Double Buffer without OpenGL Ext?
Well in the good old days, when we did have all these fancy smancy libraries ( :P ) we use to double buffer graphics by drawing to an off screen bitmap or any compatible context (to that of the screen) and then simply copy that context to the screen. I.E. 1) Create a new GtkBitmap, 2) Draw everything to the bitmap 3) copy the bits to screen EMAILING FOR THE GREATER GOOD Join me Date: Thu, 11 Feb 2010 11:41:47 -0300 Subject: How I can do Double Buffer without OpenGL Ext? From: grojas@gmail.com To: gtk-app-devel-list@gnome.org Hi, I'm working in avoid the flicker when i paint my widget draw area. Then my questions are the following: How i can to do double buffer?, but without GL Ext, using just gtk draw area and pixbuf or pixmap. And If it is posible or only can I to work double buffer with GL Ext???. Any idea? Regards. Gustavo Rojas ___ 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
RE: How I can do Double Buffer whether OpenGl Ext?
From the logo example:
/*
* Configure OpenGL-capable visual.
*/
/* Try double-buffered visual */
glconfig = gdk_gl_config_new_by_mode (GDK_GL_MODE_RGB|
GDK_GL_MODE_DEPTH |
GDK_GL_MODE_DOUBLE);
if (glconfig == NULL)
{
g_print (*** Cannot find the double-buffered visual.\n);
g_print (*** Trying single-buffered visual.\n);
/* Try single-buffered visual */
glconfig = gdk_gl_config_new_by_mode (GDK_GL_MODE_RGB |
GDK_GL_MODE_DEPTH);
if (glconfig == NULL)
{
g_print (*** No appropriate OpenGL-capable visual found.\n);
exit (1);
}
}
..
/* Set OpenGL-capability to the widget. */
gtk_widget_set_gl_capability (drawing_area,
glconfig,
NULL,
TRUE,
GDK_GL_RGBA_TYPE);
This function first tries to create a glconfig using double buffered, if fails,
uses single buffer). This works on OS X 10.6 Snow Leopard.
EMAILING FOR THE GREATER GOOD
Join me
Date: Tue, 9 Feb 2010 04:41:12 -0300
Subject: How I can do Double Buffer whether OpenGl Ext?
From: grojas@gmail.com
To: gtk-app-devel-list@gnome.org
Hi,
I'm trying to do a double buffer with pixbuf and draw area, whether to use
OpenGL Ext, but i don't know if it is posible or not.
Any idea?
Thanks.
Gustavo R.
___
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
Random crashes when printing on OS X
I am using the GtkPrint* functions to print. However at what seems to be random
occurrences the application crashes with the following error:
Gdk:ERROR:gdkeventloop-quartz.c:559:select_thread_collect_poll: assertion
failed: (ufds[i].fd == current_pollfds[i].fd)
Abort trap
When the user clicks on the print button a signal is generated and the
application comand function executes based on the following case statement:
...
case ISI_PERM_MENU_COMPONENT_FORMULA_PRINT:
if( isi_app_check_permission(prev_self,
ISI_PERM_MENU_COMPONENT_FORMULA_PRINT) prev_self-component != NULL){
isi_display_page_setup( prev_self-display,
prev_self-component,FALSE);
isi_display_print(prev_self-display);
} else {
isi_user_message(NULL,Not Allowed,You do not have
permission to print formulas.,0);
}
break;
...
void isi_display_print(IsiDisplay *self){
GtkPrintOperation *print = NULL;
GtkPrintSettings *printer_settings = NULL;
GtkPageSetup *page_setup = NULL;
GtkPaperSize *paper_size = NULL;
guint ctype;
/* Sanity Check */
g_return_if_fail(self != NULL);
g_return_if_fail(ISI_IS_DISPLAY(self) != FALSE);
g_return_if_fail(self-priv != NULL);
g_return_if_fail(self-priv-dispose_has_run != TRUE);
/* Create a new print operation */
print = gtk_print_operation_new();
/* Create new page setup and paper size */
page_setup = gtk_page_setup_new();
paper_size = gtk_paper_size_new(GTK_PAPER_NAME_LETTER);
gtk_page_setup_set_paper_size(page_setup,paper_size);
/* Set the default to the new page setup */
gtk_print_operation_set_default_page_setup(print,page_setup);
/* Make sure we always do full page printing*/
gtk_print_operation_set_unit(print,GTK_UNIT_INCH);
gtk_print_operation_set_use_full_page(print,TRUE);
gtk_print_operation_set_n_pages (print, self-priv-page_count);
g_signal_connect(print, draw-page,
G_CALLBACK(isi_display_print_event),(gpointer)self);
/* SOMEWHERE IN THIS FUNCTION THE DIALOG BLOWS UP!! */
gtk_print_operation_run(print,GTK_PRINT_OPERATION_ACTION_PRINT_DIALOG,NULL,NULL);
return;}
Any help would be greatly appreciated.
The problem is pervasive will most printer types, but is exacerbated with the
HP CP3525 Color Laserjet printer.
Shawn
EMAILING FOR THE GREATER GOOD
Join me
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: Random crashes when printing on OS X
I am now also getting this when I print, after having added a cairo_clip() to bound my drawings into a (0,0),(1,1) region. But I do not get it when I am displaying to screen, only printing, and I use the same function for both, one simply gets the cairo_t from the drawing area, the other retrieves it from the printer. Any ideas? Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:18 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:18 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:18 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:18 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:18 Shawn-Bakhtiars-iMac.local orderdesk[39199]
RE: [GtkGLExt] Window size issue
I know someone brought this up before. I don't recall if there was a resolution
to it or not.
I have successfully patched and compiled the latest from the GtkGLExt git repo
and running on OS X Snow Leopard (10.6), although I am use the 10.5 building to
the 368 architecture.
However, any application (including the examples), that uses the library, takes
over the entire window, overlapping all other widgets.
Any ideas how I should trace this down?
The code is straight out of the example (which does the same thing),
gtk_gl_init() has already been called in main, and the container is main_hbox,
which then has other widgets added to it later in the code.
glconfig = gdk_gl_config_new_by_mode (GDK_GL_MODE_RGB|
GDK_GL_MODE_DEPTH |
GDK_GL_MODE_DOUBLE);
if(glconfig != NULL){
GtkWidget * drawing_area = gtk_drawing_area_new ();
gtk_widget_set_size_request (drawing_area, 200, 200);
/* Set OpenGL-capability to the widget. */
gtk_widget_set_gl_capability (drawing_area,
glconfig,
NULL,
TRUE,
GDK_GL_RGBA_TYPE);
gtk_widget_add_events (drawing_area,
GDK_BUTTON1_MOTION_MASK|
GDK_BUTTON2_MOTION_MASK|
GDK_BUTTON_PRESS_MASK |
GDK_VISIBILITY_NOTIFY_MASK);
g_signal_connect_after (G_OBJECT (drawing_area), realize,
G_CALLBACK (realize), NULL);
g_signal_connect (G_OBJECT (drawing_area), configure_event,
G_CALLBACK (configure_event), NULL);
g_signal_connect (G_OBJECT (drawing_area), expose_event,
G_CALLBACK (expose_event), NULL);
g_signal_connect (G_OBJECT (drawing_area), button_press_event,
G_CALLBACK (button_press_event), NULL);
g_signal_connect (G_OBJECT (drawing_area), motion_notify_event,
G_CALLBACK (motion_notify_event), NULL);
g_signal_connect (G_OBJECT (drawing_area), map_event,
G_CALLBACK (map_event), NULL);
g_signal_connect (G_OBJECT (drawing_area), unmap_event,
G_CALLBACK (unmap_event), NULL);
g_signal_connect (G_OBJECT (drawing_area), visibility_notify_event,
G_CALLBACK (visibility_notify_event), NULL);
g_signal_connect_swapped (G_OBJECT (main_window), key_press_event,
G_CALLBACK (key_press_event), drawing_area);
gtk_box_pack_start (GTK_BOX (main_hbox), drawing_area, TRUE, TRUE, 0);
gtk_widget_show (drawing_area);
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Random memory allocation error
At what appears to be random locations in a program which runs thought 24000 components, and breaking out the formulas in to there raw material components (formulations table of about 200,000 formulation lines, I see this error message: malloc: *** error for object 0xe41074: incorrect checksum for freed object - object was probably modified after being freed.*** set a breakpoint in malloc_error_break to debug so far I have only found some obscure references, and this is happening randomly: IE #0 0x95f95072 in malloc_error_break ()#1 0x95f96218 in szone_error ()#2 0x95f9638b in free_list_checksum_botch ()#3 0x95ea2985 in tiny_malloc_from_free_list ()#4 0x95ea1b03 in szone_malloc_should_clear ()#5 0x95ea1988 in malloc_zone_malloc ()#6 0x95e9fa58 in malloc ()#7 0x00c2a799 in g_malloc ()#8 0x00ba774d in g_object_newv ()#9 0x00ba7ef7 in g_object_new_valist ()#10 0x00ba758f in g_object_new ()#11 0x000a8468 in isi_database_get_component_simple (self=0x101c000, aid=0x2008030 ZH, nid=90005) at isidatabase.c:4296 but it has run through the same piece of code with no problems for 30 times before it hits this. continue, and it will go past this part and break , #0 0x95f95072 in malloc_error_break ()#1 0x95f96218 in szone_error ()#2 0x95f9638b in free_list_checksum_botch ()#3 0x95ea2985 in tiny_malloc_from_free_list ()#4 0x95ea1b03 in szone_malloc_should_clear ()#5 0x95ea386b in malloc_zone_calloc ()#6 0x95ea37fa in calloc ()#7 0x00c2a82a in g_malloc0 ()#8 0x00053030 in isi_list_instance_init (instance=0x185f190, g_class=0xe1a850) at isilist.c:96#9 0x00bc196c in g_type_create_instance ()#10 0x00ba832a in g_object_constructor ()#11 0x00ba7726 in g_object_newv ()#12 0x00ba7ef7 in g_object_new_valist ()#13 0x00ba758f in g_object_new ()#14 0x0005b647 in isi_component_instance_init (instance=0x180e020, g_class=0x13a12070) at isicomponent.c:156#15 0x00bc196c in g_type_create_instance ()#16 0x00ba832a in g_object_constructor ()#17 0x00ba7a5e in g_object_newv ()#18 0x00ba7ef7 in g_object_new_valist ()#19 0x00ba758f in g_object_new ()#20 0x000a8468 in isi_database_get_component_simple (self=0x101c000, aid=0x20081b0 ZH, nid=90004) at isidatabase.c:4296#21 0xcd36 in isi_util_normalize_formuals (theApp=0x1016010, prompt=1) at isiutil.c:368#22 0xd67f in main (argc=1, argv=0xbfffe848) at isiutil.c:764 EMAILING FOR THE GREATER GOOD Join me ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: Random memory allocation error
Nailed it on the head. bad programing. I forgot how wonderful valgrind is, thanks. EMAILING FOR THE GREATER GOOD Join me Date: Sat, 26 Dec 2009 13:52:06 -0500 From: cottr...@wfu.edu To: shashan...@hotmail.com CC: gtk-app-devel-list@gnome.org; gtk-osx-us...@lists.sourceforge.net Subject: Re: Random memory allocation error On Sat, 26 Dec 2009, Shawn Bakhtiar wrote: At what appears to be random locations in a program which runs thought 24000 components, and breaking out the formulas in to there raw material components (formulations table of about 200,000 formulation lines, I see this error message: malloc: *** error for object 0xe41074: incorrect checksum for freed object - object was probably modified after being freed.*** Your code is buggy. Run it under valgrind and you'll see where the bugs are. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: GtkGLExt (was Re: Gtk 3.0)
Well... this seems to turn on a few flames... so let me put some of this to rest. For anyone to say OpenGL is niche, and does not apply to everyday apps, I again remind you of iChat and the OS X Panel. Granted it has only recently found prominence in the desktop but it is quickly making way as OGL hardware acceleration becomes standardize (has been for some time). To look back at the past decade and say look desktops are all 2D, not realizing it has to do with memory and CPU/GPU issues, which are no longer issues is simply wrong. The next decade of desktops, more importantly GUI (Graphical USER -- hello!!! Interfaces) WILL have a blinding array of 3D widgets which will be like eye candy to most users, and as they see it they will want it more and more. I do NOT work at a facility which requires 3D visualization to accomplish its tasks, but users are starting to ask and want. Can I do a walkthrough of our warehouse to see how much material I have?, Can we have a little computerized white box, with a virtualized pallet to do color matching in? This has NOTHING to do with scientific engineering or niche market. It has to do with the future of interface design. I work in a ink manufacturing plant, and by that argument, we should mix it all by hand, since that is how they did it 5000 years ago! 2D is NOT the end of all GUIs. It simply is not! R2 space can not hold as much date/widgets/whatever as R3 even if the axis were infinite! they (users) want 3D buttons that pop, role, jump, and wink at them too. They want there pictures to start bending, bouncing, and getting all organic on them. To say that GTK does NOT need OGL, is to say they sun is not going to rise in the morning. To say that GTKGLext (a great tool to be sure) is good enough, is to slap a hand in the face of all of use who see where this is going. The greatest problem with the linux community (one I myself am having to learn about) is this indelible ego that the data and function has to be correct and nothing else. Sorry if the user can not visually keep up or understand what you present, it won't make a difference how good the app works in the back, it IS the eye candy that gets the user to use it. GtkTreeview in 3D? I can thing of a dozen categorization applications in seconds. FYI - OS X is a FreeBSD engin, with NextStep as its windowing system. It uses OGL IN the windowing system (quartz / composer), and it is the hottest desktop on the market. No one, and I mean no one, has even come close! And lets not forget all the work that is being done on Compiz why? For the masochism of it?!? No! Because that is where the future of desktop are, in 3D space! IMMHO, if Gtk is to keep up, as the cross platform interface it promises to be, it will need OGL to be fully modularized or integrated somehow. I don't even think GtkGLExt is that far, other than the OS X side of it, which with demand will certainly improve. P.S.the comment: Ah. You are such a loser. Go away., has no business on this forum, the point is a good one, and your minimization of it, a poor show of understanding. EMAILING FOR THE GREATER GOOD Join me Date: Sat, 5 Dec 2009 19:48:06 +0100 From: y...@physics.muni.cz To: jose.carlos.pere...@ist.utl.pt Subject: Re: GtkGLExt (was Re: Gtk 3.0) CC: gtk-app-devel-list@gnome.org On Sat, Dec 05, 2009 at 04:22:36PM +, Carlos Pereira wrote: We must atract more scientifc/engineering applications for Linux and GTK, because this is exactly the kind of stuff that enterprises and universities are demanding. If we have fantastic operating systems and desktop environments in the free software world, but most of the scientific/engineering aplications only run in Windows/Mac OS X, people will be forced to use them, even if they would rather prefer to use Linux/BSD... I have many friends in this situation... I'm afraid you explain it from your viewpoint. But looking at your reasoning from the `desktop' viewpoint there are troubles. 1) Objective. There will never ever be a scientific `killer app'. Every little branch of science, or even an individual scientific problem, has specific needs. Hence the applications are inherently scattered and each individual app is used only by a small group of people. Even the `universal' commerical tools such as Matlab are far from being universally used [among scientists]. This makes hard to see sci/eng apps matter *at all*. 2) Subjective. Do your graphs have round corners and include the user's IM status? Can your data acquistion software synchronize the data with an iPod? Are your reports summarized to 140 characters and sent to Twitter? No? Does your app help people with some difficult to understand and much more difficult to solve problems instead of facilitating idle chit-chat while consuming power for visual effects? Ah. You are such a loser. Go away. Regards, Yeti
RE: GtkGLExt (was Re: Gtk 3.0)
I've sort of followed this chain sorry if I am rehashing something that has already been covered. IMHO I agree that GtkGLExt should be directly integrated into GTK. Most modern user interfaces (IE OS X (NextStep)) are integrating 3D directly into the windowing system. If I am not mistaken the panel is pure Open GL in OS X, and for sure the iChat multi session video window is pure OGL with reflection maps (they love to tout that). Their development toolset is chalked full of OpenGL examples, and composer... well I won't even go there. GTKGLext does NOT currently work well on OS X interface (even though there is a patch for it, which still needs to be changed to use the NSOpenGLView instead of the NSView but that is whole other story). Open GL is not only the standard scientific toolset, it is the de facto hardware acceleration tool set. I don't know of ANY video card vendor that DOES NOT have OpenGL support. In fact I can not think of any other hardware accelerated tool sets (OGL has been it since the early 90's) it WILL be the interface choice of the future. 2D desktops will quickly give way to 3D widgetry, as hardware acceleration improves even further. Just look at compiz! I've already got users asking me to make the app look more 3D, and it would be great to have the toolset to do so. Even though all were doing is simple EPR stuff. IE If I could create a 3D warehouse map that was navigable by the user to see where they have room to store a product, or look at a product space for a visual cue to order more. This is an old concept Motorola developed about its factories and training workers virtually. Of course, this is all a wish list, I can't demand of the community to do the work I my self have no time for, but it would be really really really supercalifragilisticexpialidocious-ly great to have a fully working OpenGL implementation in GTK for OS X, and if it is dropped for GTK 3.0, I'm afraid it will not serve the community well. I did not quite catch why it was not a good idea. Saying that is like saying it is not a good idea to have the printing subsystem, or input subsystem be exposed in GTK. GTK in essence is an abstraction layer, to hide the differences in interface functionality, giving the user (programer) a singe interface to write agains. Why should we not have the same thing for OpenGL, which is a component of the user interface? Again this is all MHO, and I certainly have not invested a dime in it, so wether it happens or not I will work around it, but it would be nice, very, very nice, to have an GTKOGLWindow in GTK's base library, or at least something like pango/cairo, as a compiler option module. EMAILING FOR THE GREATER GOOD Join me Date: Fri, 4 Dec 2009 22:26:05 +0100 From: y...@physics.muni.cz To: eba...@gmail.com; jose.carlos.pere...@ist.utl.pt Subject: Re: GtkGLExt (was Re: Gtk 3.0) CC: gtk-app-devel-list@gnome.org On Fri, Dec 04, 2009 at 08:51:54PM +, Carlos Pereira wrote: I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt. 4) Scientific/engineering applications often use OpenGL, Exactly. I've been using GtkGLExt in a scientific app for years and I'm quite happy with it. Cutter does not cut it if you need to visualize scientific data in 3D. Unfortunately, scientific/engineering apps seems to *be* niche use. Look at how hard SourceForge tries to hide this software category even though it contains 50× more projects than VoIP which is promimently displayed... So I hope something like GtkGLExt will continue to be available, whether it's called GtkGLExt or not and is integrated into Gtk+ or not. Yeti ___ 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
