Re: Coloring of multiple rows in List Store
Sailaxmi korada escreveu: I've a requirement, where I've to color multiple rows in List store, which are separated from each other. Is it possible to do this. Thanks for your suggestions Hi, You can use the hint property from TreeView or associate a column of ListStore with the background color from each cell. []'s Claudio ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkFileChooserButton on grabbed windows
Hi, I'm using GtkFileChooserButton and I've found that if I call gtk_grab_add on the toplevel window containing that button, then the dialog shown by the button will be un-responsive while the main window will continue to handle user events (i.e. the dialog created by the dialog is not modal). This can be seen also in gtk-demo\pickers.c adding: gtk_grab_add(window); before the call to gtk_widget_show_all(). Running the pickers sample and clicking the dir-selector or the file-selector will show two unusable dialogs... how can I avoid it (for some long-to-explain reasons, I cannot remove the gtk_grab_add call on the parent window) ? Thanks a lot ! Francesco Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
drawing area does not refresh
Hi,
I have a problem creating a function that will draw the contents of a buffer
into a drawing area.
Here is the function I call when I want to draw the contents of buffer into
the drawingarea designated by area:
int draw_in_widget(GtkWidget *area,unsigned char* buffer,int img_height,int
img_width,bool is_rgb)
{
//conversion BGR-RGB
if(!is_rgb)
{
unsigned char tmp;
for(int i=0;iimg_width*img_height;i++)
{
tmp = buffer[3*i];//B-tmp
buffer[3*i] = buffer[3*i+2];//R-B
buffer[3*i+2] = tmp;//tmp-R
}
}
gpointer destroy_fn_data;
int area_width=area-allocation.width;
int area_height=area-allocation.height;
GdkPixbuf *pixbuf_dest=gdk_pixbuf_new(GDK_COLORSPACE_RGB,FALSE,8,
area_width,area_height);
GdkPixbuf
*pixbuf_src=gdk_pixbuf_new_from_data(buffer,GDK_COLORSPACE_RGB,FALSE,8,
img_width,img_height,img_width*3,NULL,destroy_fn_data);
GdkGC *gc=area-style-fg_gc[GTK_STATE_NORMAL];
double scale_x=(double)area_width/img_width;
double scale_y=(double)area_height/img_height;
gtk_widget_queue_draw(area);
gdk_pixbuf_scale(pixbuf_src,pixbuf_dest,0,0,area_width,area_height,
0,0,scale_x,scale_y,GDK_INTERP_TILES);
gdk_draw_pixbuf(area-window,gc,pixbuf_dest,
0,0,0,0,area_width,area_height,GDK_RGB_DITHER_NORMAL,0,0);
gdk_pixbuf_unref(pixbuf_src);
gdk_pixbuf_unref(pixbuf_dest);
return(0);
}
The function adapts the size of the image contained in the buffer (of size
3*img_height*img_width) to the size of the drawing area.
My problem is that this function only works when placed in a
on_drawingarea1_expose_event handler.
If I place it somewhere else in my code, the image will only be drawn
immediately if there is no pause after my draw_in_widget function.
And I don't know how to call the on_drawingarea1_expose_event handler, since
I have no idea what arguments to give him.
The arguments asked by the handler are:
-GtkWidget *widget,
-GdkEventExpose *event,
-gpointer user_data
-
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
countries) for 2¢/min or less.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkFileChooserButton on grabbed windows
On Wed, May 10, 2006 at 05:09:53PM +0200, Francesco Montorsi wrote: I'm using GtkFileChooserButton and I've found that if I call gtk_grab_add on the toplevel window containing that button, then the dialog shown by the button will be un-responsive while the main window will continue to handle user events (i.e. the dialog created by the dialog is not modal). This can be seen also in gtk-demo\pickers.c adding: gtk_grab_add(window); before the call to gtk_widget_show_all(). Running the pickers sample and clicking the dir-selector or the file-selector will show two unusable dialogs... how can I avoid it (for some long-to-explain reasons, I cannot remove the gtk_grab_add call on the parent window) ? You can set up the file chooser dialog yourself and pass it to gtk_file_chooser_button_new_with_dialog() constructor. If the parent window is modal, setting the dialog modal too should suffice. If you for some reason do explicit grab, it does not seem to suffice and you have to g_signal_connect(dialog, show, G_CALLBACK(gtk_grab_add), NULL); g_signal_connect(dialog, hide, G_CALLBACK(gtk_grab_remove), NULL); instead (or something like that). Yeti -- Anonyms eat their boogers. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Cairo Segfaults
I have an interesting problem. I have a FC5 box set up with GTK+2.8.15. It seems when I run GTK applications through xthinpro from Windows PCs that are close in proximity to the server they run without any difficulty. However, from further distances (i.e. the server is in Washington D.C. and the xthinpro client is in New York) all the GTK applications crash with a similar backtrace as listed at the end of this email. Does anyone know what is happening here? The applications flash on the screen for a brief period of time (don't even get initialized) then crash... Thanks, Matt #1 0x00d794d9 in _cairo_pixman_composite_triangles () from /usr/lib/libcairo.so.2 #2 0x00d7a0bc in _cairo_pixman_composite_triangles () from /usr/lib/libcairo.so.2 #3 0x00d6c9f2 in _cairo_pixman_composite () from /usr/lib/libcairo.so.2 #4 0x00d5145f in cairo_font_options_create () from /usr/lib/libcairo.so.2 #5 0x00d5728f in cairo_surface_reference () from /usr/lib/libcairo.so.2 #6 0x00d4e65f in cairo_font_options_create () from /usr/lib/libcairo.so.2 #7 0x00d4e8c5 in cairo_font_options_create () from /usr/lib/libcairo.so.2 #8 0x00d4f29c in cairo_font_options_create () from /usr/lib/libcairo.so.2 #9 0x00d4f4c7 in cairo_font_options_create () from /usr/lib/libcairo.so.2 #10 0x00d4f67a in cairo_font_options_create () from /usr/lib/libcairo.so.2 #11 0x00d48779 in cairo_stroke_preserve () from /usr/lib/libcairo.so.2 #12 0x00d487a2 in cairo_stroke () from /usr/lib/libcairo.so.2 #13 0x001e7dca in clearlooks_draw_progressbar_trough () from /usr/lib/gtk-2.0/2.4.0/engines/libclearlooks.so #14 0x001e2e15 in clearlooks_style_register_type () from /usr/lib/gtk-2.0/2.4.0/engines/libclearlooks.so #15 0x003bfd0a in gtk_paint_box () from /usr/lib/libgtk-x11-2.0.so.0 #16 0x00396d55 in gtk_progress_bar_set_bar_style () from /usr/lib/libgtk-x11-2.0.so.0 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkTree cursor scoping
On Tue, 2006-05-09 at 10:50 -0400, Hassaan Khan wrote: 1. is it possible for the cursor not to move during an update for TreeView2 while the u If not how do i make sure that the cursor returns to the correct TreeView after an upda This doesn't answer your question (sorry) but may help you to answer them yourself... Thee term you are looking for is keyboard focus, I think, rather than cursor scoping. -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: newbie and ask show window
Le mercredi 10 mai 2006 à 13:23 +0700, Ade Amrillah a écrit :
hi all
i'm newbie in gtk+. i was create simple programme for testing
gtk_widget_show() function.
my program has tow windows
first window i put button for call second window, i develop GUI with
Glade and anjuta for code.
my code are
void on_openbtn_clicked (GtkButton *button,gpointer user_data)
{
GtkWidget * window2;
window2=create_window2();
gtk_widget_show(window2);
}
and it's working. but if i press button again a new window (window2)
will be create.
i want just one window created if i press again button.
ask: how i change the programme for show window for only one show?
for illustrated:
i use gedit and i click preferences (menu edit-preperences) just one
window showed and if i click again did not show again new window.
sorry for my english :)
Use something like:
GtkWidget * window2 = NULL;
void on_openbtn_clicked (GtkButton *button,gpointer user_data)
{
if (window2 != NULL)
return;
window2=create_window2();
gtk_widget_show(window2);
}
and add an event handler to reste window2 to NULL when the window is
destroyed.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkBuilder status
Hi
Over the last couple of weeks Henrique Romano and I have been working on
GtkBuilder, a UI constructor intended for inclusion in GTK+.
I'd like to discuss the API and some of the decisions before making the
code available for public review.
This work has been sponsored by Nokia.
We've made a couple of important decisions:
* GMarkup based parser which parses and creates the object tree in one step
go instead of saprving a whole tree in memory.
* breaking xml format compatibility with libglade
* not supporting any deprecated or broken widgets
* only supporting menubar and toolbar construction through GtkUIManager
* custom/fake properties are not intended to be supported. Instead
functionality relying on them needs to be rewritten.
We also intend to write a script which will help convert a file
saved by libglade into a file which can be loaded by GtkBuilder.
XML Format
==
Versus libglade
glade-interface is renamed (to interface or builder, TBD)
widget becomes object
object has a new attribute, constructor
object can have type specific child tags after the child child tag.
child has a new attribute, type
require is removed
Support for atk is not implemented yet, but it will be different
from the way libglade does it.
GtkBuilder API
==
Against the libglade api
get_widget becomes get_object
get_widget_prefix becomes get_objects and the argument is removed.
filename is no longer an attribute, instead a property is added
a domain property is added
a signal finish is added
the virtual method lookup_type is removed
set_custom_handler is removed
construct is removed
GtkBuildable
Is an interface which an object needs to implement if it wishes to have
a specialized behavior:
* set_name, to be able to reuse the name set by the builder
* add, for adding a child to a parent
* construct_child, for specialized construction, used by mainly by widgets
created by a GtkUIManager
* custom_tag_start/custom_tag_finish: for custom tags, see below
* set_child_property, used to set child/packing properties in a container.
Type specific tags
==
GtkUIManager
ui tag which embeds the normal GtkUIManager definition.
GtkListStore
columns which has a child tag called column with an attribute called
type which value is the type name of the column.
GtkTreeStore
columns identical to GtkListStore
GtkSizeGroup
widgets which has a child tag widget with an attribute called name
which is the name of the widget which is part of the sizegroup.
widgets
widget name=entry1/
widget name=entry2/
/widgets
GtkTreeModel will add one or several tags to allow data to be specified in
the xml format.
GtkCellRenderer or GtkTreeViewColumn will gain an additional tag to allow
attributes to be set.
Comments, suggestions?
--
Johan Dahlin [EMAIL PROTECTED]
Async Open Source
/* gtkbuilder.h
* Copyright (C) 2006 Async Open Source
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Library General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Library General Public License for more details.
*
* You should have received a copy of the GNU Library General Public
* License along with this library; if not, write to the
* Free Software Foundation, Inc., 59 Temple Place - Suite 330,
* Boston, MA 02111-1307, USA.
*/
#ifndef __GTK_BUILDER_H__
#define __GTK_BUILDER_H__
#include glib-object.h
G_BEGIN_DECLS
#define GTK_TYPE_BUILDER (gtk_builder_get_type ())
#define GTK_BUILDER(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), GTK_TYPE_BUILDER, GtkBuilder))
#define GTK_BUILDER_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), GTK_TYPE_BUILDER, GtkBuilderClass))
#define GTK_IS_BUILDER(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), GTK_TYPE_BUILDER))
#define GTK_IS_BUILDER_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), GTK_TYPE_BUILDER))
#define GTK_BUILDER_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), GTK_TYPE_BUILDER, GtkBuilderClass))
typedef struct _GtkBuilderGtkBuilder;
typedef struct _GtkBuilderClass GtkBuilderClass;
struct _GtkBuilder
{
GObject parent;
};
struct _GtkBuilderClass
{
GObjectClassparent_class;
void (*finish) (GtkBuilder *);
/* Padding for future expansion */
void (*_gtk_reserved1) (void);
void (*_gtk_reserved2) (void);
void (*_gtk_reserved3) (void);
void (*_gtk_reserved4) (void);
};
GType gtk_builder_get_type (void) G_GNUC_CONST;
GtkBuilder*gtk_builder_new(const gchar *filename,
const gchar *domain);
GtkBuilder*gtk_builder_new_from_buffer(const gchar *buffer,
Re: Solaris fopen issue
On Wed, 2006-05-10 at 18:37 +0400, Kirill Kirichenko wrote: Hi folks. I have run into problems of GTK using fopen on Solaris. The Solaris implementation has a problem with any fopen() which opens a file above the 256 file descriptor. How can I get around the problem ? I use gtk 2.4.9 on Solaris 5.10. I created a program that emulates my situation. It's a simple Hello World GTK application that opens 300 file descriptors with open(2) before gtk_init called. It crashes with mesages below: The Solaris implementation has a problem with any fopen() which opens a file above the 256 file descriptor. I'm slightly speechless here, though I'm sure there are valid historical compatibility reasons for why Sun can't fix that problem. I'd suggest, if you really need that many file descriptors *open*, maybe just start your GUI earlier ... the use of stdio in pango and fontconfig is limited to reading configuration files. It *would* of course, be possible to rewrite Pango to not use stdio, and use, say, GIOChannel instead. Feel free to file a bug report in Bugzilla to that effect, but don't expect it to get high prioritization, unless Sun has a patch sitting around Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Solaris fopen issue
I brought this up in Nov05 here: http://mail.gnome.org/archives/gtk-devel-list/2005-November/msg00135.html And Joseph Kowalski (a SunOS engineer) responded here: http://mail.gnome.org/archives/gtk-devel-list/2005-November/msg00196.html I had a friendly chat with him offline. The 64-bit ABI was their chance to right this particular issue. Andrew Paprocki Bloomberg LP On Wed, 2006-05-10 at 10:58 -0400, Owen Taylor wrote: The Solaris implementation has a problem with any fopen() which opens a file above the 256 file descriptor. I'm slightly speechless here, though I'm sure there are valid historical compatibility reasons for why Sun can't fix that problem. I was so surprised I did a bit of Googling. The easy solution to the problem is to compile your code in 64-bit mode, as this limitation only applies to the 32-bit ABI (from fopen man page): ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Solaris fopen issue
How about allocating your own file descriptors above 256, then? I.e., you would allocate them as usual (not using fopen, one assumes) and then dup them up to some unused descriptor up there and close the original. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Solaris fopen issue
From: Owen Taylor [EMAIL PROTECTED] ... I have run into problems of GTK using fopen on Solaris. The Solaris implementation has a problem with any fopen() which opens a file above the 256 file descriptor. How can I get around the problem ? I use gtk 2.4.9 on Solaris 5.10. I created a program that emulates my situation. It's a simple Hello World GTK application that opens 300 file descriptors with open(2) before gtk_init called. It crashes with mesages below: The Solaris implementation has a problem with any fopen() which opens a file above the 256 file descriptor. I'm slightly speechless here, though I'm sure there are valid historical compatibility reasons for why Sun can't fix that problem. I'd suggest, if you really need that many file descriptors *open*, maybe just start your GUI earlier ... the use of stdio in pango and fontconfig is limited to reading configuration files. It *would* of course, be possible to rewrite Pango to not use stdio, and use, say, GIOChannel instead. Feel free to file a bug report in Bugzilla to that effect, but don't expect it to get high prioritization, unless Sun has a patch sitting around Ah yes, the legendary 256 file limit on stdio. This topic came up 6-9 months ago. I remember answering the why? question in private. Maybe I should answer it in public. After all, I was there. If you want to shoot somebody for this oversight, you can shoot me; I was the project lead for the SunOS portion of Solaris 2.0 (Solaris 0 by the new naming). The macro was missed as an issue. Besides, things were a bit different in 1989. The System V ABI, and early Solaris releases have fileno as a macro. This means that the **byte** which contained the file number in the FILE structure was hardwired into the application (macros - just say no). Sun (or at least the Solaris organization) pays more attention to binary computability than just about anybody. You probably wouldn't believe the things we worry about for compatibility. Certainly something in the ABI and stdio got a lot of respect. Most (all?) the other System V vendors just made the *incompatable* change years ago and forced a recompile. Well, the good news is that this respect has run out. In SunOS 5.7/Solaris 7 the fileno() macro was removed from the headers; only a real function exists. Just a month or so ago, a change was put into Solaris to remove this restriction in the belief that anything compiled on Solaris 6 or earlier is either dead or irrelevant. The change is quite complicated (to maintain computability in the absence of the fileno() macro) but you'ld almost never know it was there. I'd assume by now its in the OpenSolaris world. Sun never commits to contents of future releases, but this is targeted for the next Solaris release and patches for existing releases. I don't know which releases patches are targeted for and even if I did I couldn't tell you. Just watch for Solaris patches in the not too distant future. This probably doesn't do any of you any good today. The best practice work around is to force all your non-stdio files to be greater than 256... my_silly_fd_counter = 256; ... tfd = open( ... ); fd = dup2(tfd, my_silly_fd_counter++); close(tfd); These leaves the file descriptors less than 256 available for stdio use in libraries. Pretty weird, huh? The good news is you can hide this away in a little routine and isolate the weirdness. A kludgier approach is just to do a few dummy opens early in the program flow and close them just before calling the library known to want to do stdio. This goes beyond the API, so its not guaranteed to work, and is even more gross than the best practice above (IMHO), but may result in less lines of code changed. - cheers, - Joseph Kowalski Any opinions expressed are my own and not those of Sun Microsystems Inc. Yadda, yadda, yadda, ... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Problem with preview and the blocking print dialog
I'm implementing the preview code in gtkprint. I have decided to use an external helper (default is evince) to do print preview. The idea was to write out to a pdf in /tmp and launch the external helper when the user hits the preview button. The print dialog would stick around even after the preview button was pressed. The issue with the blocking dialog is that, while we can keep the dialog from going away, the way the code is structured right now we would have to wait until the preview was done before reattaching to gtk_dialog_run. This leaves a gap where the user can hit a button on the dialog and nothing will happen. There are a couple of solutions as I see them: 1) We could gray out the dialog while the preview is being generated 2) Restructure _gtk_print_operation_platform_backend_run_dialog so that we setup the print before we return instead of it happening in the calling function. 3) Move to a completely async dialog With 1 we need to figure out a way to reenter _gtk_print_operation_platform_backend_run_dialog without cleaning up or reinitializing data. With 2 we end up possibly duplicating code across platforms Is 3 plausible on Windows and Mac? I sort of like 3 since it simplifies some things by having 1 API for sync/async in that we could restrict input to the calling window even if the underlying code is async. As it is now I can generate a preview by simply having the dialog dismissed. I am going to post that patch sometime tomorrow so you can get a better idea of what I am talking about. -- 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: Problem with preview and the blocking print dialog
On Wed, 2006-05-10 at 17:42 -0400, John (J5) Palmieri wrote: I'm implementing the preview code in gtkprint. I have decided to use an external helper (default is evince) to do print preview. The idea was to write out to a pdf in /tmp and launch the external helper when the user hits the preview button. ignorant Why do we have an external helper? Gnome-print would save everything to its own internal metafile, and then it would spit it to a gnome-canvas. Could we make Cairo just render everything to a preview window? /ignorant Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem with preview and the blocking print dialog
John (J5) Palmieri wrote: This was my original thought but Matthias and others suggested this. One of the issues with cairo is that we would have to either run through the drawing commands on every expose event or save out to a bitmaps surface which would remove the ability to zoom. The other option is to recreate evince in gtk+. That is not going to happen. One issue is that there's a good chance evince won't be installed on win32 or OS X. I'm a bit unclear on what you're doing though. I'd have thought there'd be a preview widget that would need to handle expose events and render as appropriate. As far as the question about about print dialog modality, the win32 dialog api is designed to block until the dialog is closed. It might be possible to work around this using threads, but it would be ugly. I'm not entirely clear on why the helper app needs to be closed before the dialog is closed, though. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem with preview and the blocking print dialog
On Wed, 2006-05-10 at 18:56 -0400, John Ehresman wrote: John (J5) Palmieri wrote: This was my original thought but Matthias and others suggested this. One of the issues with cairo is that we would have to either run through the drawing commands on every expose event or save out to a bitmaps surface which would remove the ability to zoom. The other option is to recreate evince in gtk+. That is not going to happen. One issue is that there's a good chance evince won't be installed on win32 or OS X. I'm a bit unclear on what you're doing though. I'd have thought there'd be a preview widget that would need to handle expose events and render as appropriate. win32 and OS X use their own dialogs. I haven't yet looked at the issue of enabling previews there. As far as the question about about print dialog modality, the win32 dialog api is designed to block until the dialog is closed. It might be possible to work around this using threads, but it would be ugly. Eak, ugly :-) I'm not entirely clear on why the helper app needs to be closed before the dialog is closed, though. No it doesn't. The dialog just needs to stick around even after we run the helper app. -- 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: Problem with preview and the blocking print dialog
This was my original thought but Matthias and others suggested this. One of the issues with cairo is that we would have to either run through the drawing commands on every expose event or save out to a bitmaps surface which would remove the ability to zoom. The other option is to recreate evince in gtk+. That is not going to happen. Or convince Carl to make the meta surface a public API before 1.2 hits the streets, and make whatever improvements are necessary for that to happen. That's essentially what GnomePrint does, anyway. Best, Dom -- Counting bodies like sheep to the rhythm of the war drums. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problem with preview and the blocking print dialog
On Wed, 2006-05-10 at 19:37 -0400, Dominic Lachowicz wrote: This was my original thought but Matthias and others suggested this. One of the issues with cairo is that we would have to either run through the drawing commands on every expose event or save out to a bitmaps surface which would remove the ability to zoom. The other option is to recreate evince in gtk+. That is not going to happen. Or convince Carl to make the meta surface a public API before 1.2 hits the streets, and make whatever improvements are necessary for that to happen. That's essentially what GnomePrint does, anyway. Carl says this is not going to happen but if I understand him correctly the pdf or ps surface preserves the cairo_meta_surface_t and can be used as a source for painting. -- 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: GtkBuilder status
Over the last couple of weeks Henrique Romano and I have been working on GtkBuilder, a UI constructor intended for inclusion in GTK+. I'd like to discuss the API and some of the decisions before making the code available for public review. I went ahead and attached the patch to http://bugzilla.gnome.org/show_bug.cgi?id=172535 Johan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder status
o One concern I have is about the format, the way it seems... oddball cases are being treated by introducing new tags in the format specificly for those cases. Is there a reason they cant be handled as properties ? example: property id=colunmsSTRING, INT, INT/property property id=widgetsentry1, entry2/property My feelings here are that introducing these new tags in a way removes freedom from the implementing IBuildable (if GtkSizeGroup implements a widgets property of GParamSpecObjectList type, it will still need taillored load code to deal with the hard-coded special casing tags found in the glade files). Furthermore; implementing every parameter as a property allows (forces) all special-case code to be implemented with the same prototypes (i.e. libglade's _register_custom_prop() ), probably resulting in IBuildable code that is in the long run; more maintainable. I don't think such fake genericity will buy as much. The difference between a new tag and a new value of the property attribute is not that big, when it comes to doing the right thing with it... o My real concern is about supporting menus and toolbars built by UIManager. - Is the motivation here only a time-to-market thing ? - If so, do you have any plan or stratagy to take baby-steps and eventually get all the ui building code into the IBuildable ? From what I've seen, the IBuildable architechture provides exactly what is needed to generate menus and toolbars directly, and more powerfully than the UIManager (does UIManager allow you to set properties on every object in its heirarchy individually ? ... can you refer to an object in the UIManager from the rest of the glade file ? for a random example: Say I want the mnemonic widget on a label somewhere in the UI to be a GtkToolItem). Ofcourse I'm not saying that UIManager is bad, its provided some convenient apis to build complex menus and get all that GtkAction stuff in order, but now that we are introducing a complete builder into gtk+, it should be time for UIManager to die. Building menus and toolbars and getting it right is complex, if man-power is the issue; I will drop everything else for the time it takes to write IBuildable GtkMenuShells, GtkMenuItems menubars, toolbars, toolitems etc myself (since I am so demanding... I must offer to share in the bloodshed). Nothing wrong with allowing buildable menus or toolbars, but how do you propose that they should achieve what uimanager does, mainly separation of ui and actions, and merging of uis ? Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder status
Johan Dahlin wrote: Over the last couple of weeks Henrique Romano and I have been working on GtkBuilder, a UI constructor intended for inclusion in GTK+. I'd like to discuss the API and some of the decisions before making the code available for public review. I went ahead and attached the patch to http://bugzilla.gnome.org/show_bug.cgi?id=172535 Why remove custom properties? They are still needed by applications, since an application can't extend parser nor can it override existing Bulidable interface (i guess it is possible, but in the same way as it's possible to add/override properties in existin class). Regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
