acces to a member of the principal widget
Hi,
I looked for days my error, and I found it ;).
in a menu bar I add item. This item open an gtk_file_chooser_dialog.
In the callback of my main I give as argument the pointer of my mani widget
pWindow.
But how can I access to my list, which is add by a gtk_add_container to my
pWindow widget ?.
{
pWindow = gtk_window_new (GTK_WINDOW_TOPLEVEL);
...
DirList = gtk_clist_new_with_titles (3, DirTitles);
g_signal_connect_swapped(G_OBJECT(pMenuItem), activate,
G_CALLBACK(OnFile), (GtkWidget*) pWindow);
gtk_container_add (GTK_CONTAINER (scrolled_window), DirList);
}
void OnFile ( gpointer data )
{
GtkWidget *pFileSelection;
GtkWidget *pDialog;
GtkWidget *pParent;
gchar *sChemin;
pParent = GTK_WIDGET(data);
.
// Now I would like to access to my DirList Widget ? //
}
Can you tell me if it exists macros to access to member of the principal
widget ?
Cheers
Jerome
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Columns with no cursor on GtkTreeView
Hi list. I have a GtkTreeView with a lot of columns amd only some of them are editable. It works fine. What i want to do is that the cursor doesn't position over some of the columns (the non editable ones) for practical use reasons. Is there any property to set this or i have to make a funcion hooked on cursor movement cheking current position and direction to set the new destination? Thanks! Saludos, Juan Pablo. __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - 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
Re: acces to a member of the principal widget
On 3/27/06, Jerome Le Saux [EMAIL PROTECTED] wrote:
Hi,
I looked for days my error, and I found it ;).
in a menu bar I add item. This item open an gtk_file_chooser_dialog.
In the callback of my main I give as argument the pointer of my mani widget
pWindow.
But how can I access to my list, which is add by a gtk_add_container to my
pWindow widget ?.
{
pWindow = gtk_window_new (GTK_WINDOW_TOPLEVEL);
...
DirList = gtk_clist_new_with_titles (3, DirTitles);
g_signal_connect_swapped(G_OBJECT(pMenuItem), activate,
G_CALLBACK(OnFile), (GtkWidget*) pWindow);
gtk_container_add (GTK_CONTAINER (scrolled_window), DirList);
}
void OnFile ( gpointer data )
{
GtkWidget *pFileSelection;
GtkWidget *pDialog;
GtkWidget *pParent;
gchar *sChemin;
pParent = GTK_WIDGET(data);
.
// Now I would like to access to my DirList Widget ? //
}
Can you tell me if it exists macros to access to member of the principal
widget ?
Hello,
You'd better connect with g_signal_connect() like:
g_signal_connect (pMenuItem, activate, G_CALLBACK (OnFile), pWindow);
and change the OnFile callback like:
static void
OnFile (GtkMenuItem *menu_item, GtkWidget *window)
{
/* ... */
}
Olexiy
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
About gtk text view
Hello, I'm making a program that displays a text view, and I cant find the right keywords to find the solution on the archives: I need to know when the gtk_text_view window changes size(the user force that with the mouse), so I can redraw the screen. But seems the configure_event is deactivated for child windows(those that are not the main one), so I use the expose event that is far from perfect. gtk_text_view is very SLOW, I know why, I'm receiving expose event for each line I write in the text buffer. I know by default all widgets are double buffered, so I need to disconnect screen updating while writing, when I have finished use something like gtk_widget_show. The problem, I don't know how: :-) Does someone know the solution of any of these two problems ? Jose Hevia ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Callbacks and widgets
On Tue, Mar 28, 2006 at 09:38:20AM +0200, Gonzalo Aguilar Delgado wrote: Because receiver callback is getting only the receiver widget, In addition, the callback gets an arbitrary pointer passed as user_data to g_signal_connect(). A pointer can be used to pass anything. This is a very frequently asked question, search the archives for discussion... 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: The printing work has been merged
Hey, First of all, I implemented some printing in my application, and it works! I have a question about generating postscript. Using copy/paste method I implemented postscript print backend, and it's working fine. While generated postscript is just a bunch of page images due to cairo problems, the GtkPrint* stuff works fine. So, shouldn't PDF backend be really a File backend which can write PDF or PS? Or maybe just separate PS backend, in addition to PDF? Best regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
The printing work has been merged
Matthias Clasen writes: For cvs cairo, it should be turned on by default. Er, what *cvs* cairo? ;) I've been too lazy to install git, are there nightly snapshot tarballs anywhere? --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The printing work has been merged
Le lundi 27 mars 2006 à 02:08 -0600, Yevgen Muntyan a écrit : Hey, First of all, I implemented some printing in my application, and it works! I have a question about generating postscript. Using copy/paste method I implemented postscript print backend, and it's working fine. While generated postscript is just a bunch of page images due to cairo problems, the GtkPrint* stuff works fine. So, shouldn't PDF backend be really a File backend which can write PDF or PS? Or maybe just separate PS backend, in addition to PDF? An what about an EPS backend? I feel it might be useful for many people (not only myself). Cheers, Jean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The printing work has been merged
Jean Bréfort wrote: An what about an EPS backend? I feel it might be useful for many people (not only myself). I believe it would be an easy option of PS backend (or whoever would print postscript), EPS is just PS without some header, right? Regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The printing work has been merged
On Mon, 2006-03-27 at 04:57 -0600, Yevgen Muntyan wrote: I believe it would be an easy option of PS backend (or whoever would print postscript), EPS is just PS without some header, right? As I understand it EPS is a subset of PostScript. Pure PostScript can do anything, such as create new pages, be a web server, etc. Encapsulated PostScript is designed for embedding in other documents, so it more like SVG in that respect: lots of the functionality isn't supported, EPS files have more explicit bounding boxes, etc. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF 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: Building problems on mac intel
Hello, I am attempting to build gtk+ on the new macbook pro (mac os x 10.4.5 intel). Hi Lillian, I've committed the relevant fixes so everything should (hopefully) build now. Anders ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The printing work has been merged
On 3/27/06, Tor Lillqvist [EMAIL PROTECTED] wrote: Matthias Clasen writes: For cvs cairo, it should be turned on by default. Er, what *cvs* cairo? ;) I've been too lazy to install git, are there nightly snapshot tarballs anywhere? Hah, good point. Me too. I'm hoping that cairo 1.2 is near now... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gnome_client and project ridley
Hello there's a gnome bug [1] concerning the possible replacement of GnomeClient as part of Project Ridley. The libgnome page in the wiki [2] has the following interesting bit: 'But my view is that GNOME should drop XSMP entirely and just have a startup programs folder and dbus services. -hp' what is the current thinking on this matter? The bug has a more ambitious goal than just replacing the gnome client API from what I see as it covers saving widgets and windows status not just application parameters traditionally (?) saved as part of the session. Right now there are quite a few gnome apps which of the Gnome APIs only use gnome_client, but get linked to all the libraries because of this dependency. thanks Jani [1] http://bugzilla.gnome.org/show_bug.cgi?id=79285 [2] http://live.gnome.org/LibgnomeMustDie ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The printing work has been merged
On Mon, 2006-03-27 at 12:57 +0100, Ross Burton wrote: On Mon, 2006-03-27 at 04:57 -0600, Yevgen Muntyan wrote: I believe it would be an easy option of PS backend (or whoever would print postscript), EPS is just PS without some header, right? As I understand it EPS is a subset of PostScript. Pure PostScript can do anything, such as create new pages, be a web server, etc. Encapsulated PostScript is designed for embedding in other documents, so it more like SVG in that respect: lots of the functionality isn't supported, EPS files have more explicit bounding boxes, etc. A specific issue in this case is that i don't think EPS files can contain multiple pages. This means its not really possible to create EPS files in the print backend. EPS files are more meant to be used for clipart-style images. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a hate-fuelled neurotic boxer on the edge. She's a transdimensional bisexual Hell's Angel living on borrowed time. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The printing work has been merged
Alexander Larsson wrote: On Mon, 2006-03-27 at 02:08 -0600, Yevgen Muntyan wrote: Hey, First of all, I implemented some printing in my application, and it works! Cool! Did you like the API? I followed print-editor.c, so I subclassed GtkPrintOperation and I do stuff in begin-print and draw-page methods; it works fine. But, I do not understand how can a library provide printing. It seems inappropriate for a text widget to create a GtkPrintOperation object; and it seems natural (maybe after gnomeprint?) to delegate the real job to some PrintJob object which could be sent to a printer, or used inside of PrintOperation methods. E.g. it feels just wrong that drawing happens in the method of an object which also shows Print dialog. I looked at GtkPrintJob, but it seems to be rather internal auxiliary class not intended for using in application code. Maybe it's just my misunderstanding, but documentation is not very clear ;) From the other hand, this straight prepare-and-print way is awesome. I love how it's easy to print a text document. In any case, it would be really cool if you wrote some five-steps printing howto or a rough description of what doing what. Do we want to expose a write-to-ps to everyone? PDFs are a well known way to send pre-rendered page layouts as files, but postscript is much less widely known. Well, in our department network consisting of linux machines, xerox postscript printers, and lpr, postscript is widely known. I personally need postscript much more than pdf here, since I can create postscript file, ssh to some department machine, and send the file to print using lpr. If I have pdf, I use wonderful acrobat reader to print file to PS, and so on. And well, postscript is not something ancient and forgotten. People dealing with TeX know about postscript. postscript is much less widely known is rather like MS Word format is very well known. Technically it would be easy to make the pdf backend be a general backend that had a pdf or ps setting in the advanced tab. I'm just not sure if exposing that is a good idea. Opinions? I believe it should be a well-visible option in the dialog, like a combo with PS and PDF in the list. It's really a I press Print and choose Print to PS thing, not something set once and forgotten forever (of course dialog must remember last choice). Best regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Input methods
On Thursday at 18:30, Simos Xenitellis wrote: This works ok for most languages now, though there is some work to synch the table from upstream http://bugzilla.gnome.org/show_bug.cgi?id=321896 Not really. X Compose files allow a compose sequence to return a string of UTF-8 characters, while internal Gtk+ compose handling doesn't allow that. This is problematic for when you don't have precomposed accented letters in Unicode/ISO 10646, so you must use decomposed form. Cheers, Danilo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The printing work has been merged
On Mon, 2006-03-27 at 12:47 -0600, Yevgen Muntyan wrote: Alexander Larsson wrote: On Mon, 2006-03-27 at 02:08 -0600, Yevgen Muntyan wrote: Hey, First of all, I implemented some printing in my application, and it works! Cool! Did you like the API? I followed print-editor.c, so I subclassed GtkPrintOperation and I do stuff in begin-print and draw-page methods; it works fine. But, I do not understand how can a library provide printing. It seems inappropriate for a text widget to create a GtkPrintOperation object; and it seems natural (maybe after gnomeprint?) to delegate the real job to some PrintJob object which could be sent to a printer, or used inside of PrintOperation methods. E.g. it feels just wrong that drawing happens in the method of an object which also shows Print dialog. I looked at GtkPrintJob, but it seems to be rather internal auxiliary class not intended for using in application code. Maybe it's just my misunderstanding, but documentation is not very clear ;) While its possible to subclass GtkPrintOperation (that was very much in the design) I don't expect that to be the main way apps will use it. I think the main way will be to create a non-subclassed PrintOperation object and connecting to the draw_page signal on it. If some object want to provide printing i think the best way is to make it have an method that can render itself to a cairo_t. GtkPrintJob is an internal object in the unix printing implementation. It is not used in for instance the Win32 port. In any case, it would be really cool if you wrote some five-steps printing howto or a rough description of what doing what. I need to write full API docs of course, but I also want to write some sort of tutorial. Actually I intend to present this on guadec, so the paper for Guadec will probably be some form of tutorial. Do we want to expose a write-to-ps to everyone? PDFs are a well known way to send pre-rendered page layouts as files, but postscript is much less widely known. Well, in our department network consisting of linux machines, xerox postscript printers, and lpr, postscript is widely known. I personally need postscript much more than pdf here, since I can create postscript file, ssh to some department machine, and send the file to print using lpr. If I have pdf, I use wonderful acrobat reader to print file to PS, and so on. While I have personally printed to ps and scp:d it to another machine to print I think that is a sort of fringe usecase, and more of a hint of how broken the unix print system is. Maybe we should support it, but far more important is to obsolete this workaround so that not only people like us can manage to print on remote printers. :) And well, postscript is not something ancient and forgotten. People dealing with TeX know about postscript. postscript is much less widely known is rather like MS Word format is very well known. Both TeX and MS Word are stuff that end users care about, but postscript is less so. Its more of a necessary evil that users of TeX are forced to know about the details of postscript, as its really just an implementation detail in the unix printing system. In reality people will be forced to work with postscript files, so we should have some form of support for it, but the imho goal should be to move away from users having to know about this stuff. Technically it would be easy to make the pdf backend be a general backend that had a pdf or ps setting in the advanced tab. I'm just not sure if exposing that is a good idea. Opinions? I believe it should be a well-visible option in the dialog, like a combo with PS and PDF in the list. It's really a I press Print and choose Print to PS thing, not something set once and forgotten forever (of course dialog must remember last choice). I don't quite agree with well visible, but this sounds like a generally good thing, as long as we default to PDF, because that is really a much more viable format for passing pre-rendered files between different machines and platforms. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a one-legged coffee-fuelled paramedic with a mysterious suitcase handcuffed to his arm. She's a time-travelling insomniac mermaid on the trail of a serial killer. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ Mac Precompiled binaries?
Hello, I visited the page for Gtk Mac OS X because GTK was listed as a prerequisite for a Mac program I'd like to try. I have yet to compile a program in the shell on a Mac, and I was hoping to find some precompiled binarys that I could just install. Any chance such a thing exists somewhere, or if not, that offereing some precompiled binaries for download might be considered? Thank You, -john ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
