Re: Embed theme with a gtk app?
Yes there is a way.
Here is how I have done it.
gchar *rc_files[] = { path to your rc file, NULL};
gtk_rc_set_default_files (rc_files);
Regards,
Tomas Soltys
Is there any way to either embed or make a gtk program load a theme
that comes with the program, without the user having to install
anything else. I have some programs mainly for windows that look like
absolute rubbish when on the default theme, but alot of my users on
the windows version have the DLL's all over the place.
___
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: GtkImage
2009/1/29 Dov Grobgeld dov.grobg...@gmail.com: The GtkImage will change its size automatically according to the size of the image that you load. If you want to change the image size, then you should load it into a GdkPixbuf, resize it, and then set it with gtk_image_set_from_pixbuf(). Btw, please keep CC:ing the mailing list, as there might be others with similar questions. Regards, Dov 2009/1/29 frederico schardong frede@gmail.com Hi, But I must resize the image to the size of space of GtkImagem on .glade.. how I do it? But GtkImage don't change its size.. On glade I defined the size of GtkImage, that is not preventing it to resize? Thanks ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkImage
In glade, try erasing the size. There is almost never any need to set the size of a widget in glade. Instead the size of a widget should be the size of its contained widgets. Regards, Dov 2009/1/29 frederico schardong frede@gmail.com 2009/1/29 Dov Grobgeld dov.grobg...@gmail.com: The GtkImage will change its size automatically according to the size of the image that you load. If you want to change the image size, then you should load it into a GdkPixbuf, resize it, and then set it with gtk_image_set_from_pixbuf(). Btw, please keep CC:ing the mailing list, as there might be others with similar questions. Regards, Dov 2009/1/29 frederico schardong frede@gmail.com Hi, But I must resize the image to the size of space of GtkImagem on .glade.. how I do it? But GtkImage don't change its size.. On glade I defined the size of GtkImage, that is not preventing it to resize? Thanks ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: jpeg to bmp with pixbuf
Adding gtk-app-devel-list back. Please don't respond privately. .bmp Uncompressed image. Without any image compression algorithm. Hmm. .bmp is a file format, and as it has several parameters that can vary independently, effectively a collection of subformats. (Not all of the possible parameter settings occur in practise in real-life .bmp files out there, except intentionally produced samples, and not even Microsoft's own software like IE necessarily correctly displays .bmp files with some rare parameter combinations.) If what you want is to read in a jpeg file and write out a bmp file, why didn't you simply say so? Anyway, yes, you can do that with gdk-pixbuf. Load the image using the jpeg loader, save it using the bmp loader. The gdk-pixbuf API is quite simple, it shouldn't be hard to figure out yourself. If what you actually want is an in-memory uncompressed image, then yes, that is what loading an image from a file (or from a file's data in memory) into a GdkPixbuf does. The pixel data in a GdkPixbuf is one byte per channel per pixel. It won't be organised in memory in a way that exactly would correspond to the data of the most common .bmp file formats, though. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Status Indication GUI development using GTK++
Hello, I have just newly subscribed to thie mailing list and wanted to post a question. I am doing application development on Fedora Core 6 Linux Machine. I need to implement the status indication GUI such that it could display a simple traffic light indication i.e, green light for success and red light for error. Can someone suggest me a link where I can get an example code doing thhis type of thing so that I could learn or modify it suit my requirement. Thnaks for your help and regards, Adeel Malik ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_malloc overhead
On Sun, 18 Jan 2009 17:43:57 +0100 Martín Vales mar...@opengeomap.org wrote: Other overhead i see is the open dir/file funtions, where in windows we need do the utf8 to utf16 everytime in windows. If JAVA,.NET and Qt use utf16 by default why in gnome world we use utf8 by default?. Probably one of the biggest reasons, is that UTF-8 does not use \0 octets, whereas UTF-16 does. This means that UTF-8 data can transparently pass through all of the usual str*() functions in C, such as strlen(), strcpy(), etc... -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_malloc overhead
Am Montag, den 26.01.2009, 12:40 +0100 schrieb Martín Vales:
Paul LeoNerd Evans escribió:
On Sun, 18 Jan 2009 17:43:57 +0100
Martín Vales mar...@opengeomap.org wrote:
Other overhead i see is the open dir/file funtions, where in windows we
need do the utf8 to utf16 everytime in windows. If JAVA,.NET and Qt use
utf16 by default why in gnome world we use utf8 by default?.
Probably one of the biggest reasons, is that UTF-8 does not use \0
octets, whereas UTF-16 does. This means that UTF-8 data can transparently
pass through all of the usual str*() functions in C, such as strlen(),
strcpy(), etc...
I can see the advantages of use utf8 but the true it´s most of people
use utf16. I know gnome/linux/cairo/freedesktop promote utf8 but most
people use utf16:
http://unicode.org/notes/tn12/#Software_16
Currently C doesn't support for UTF-16 literals. The wchar_t type is 32
bits on Linux. So instead of:
do_something (abc)
you'd suddenly have to write:
const utf16_t abc_literal[] = { 65, 66, 67, 0 }; /* abc */
do_something (abc_literal);
I really don't see how this would help.
Ciao,
Mathias
--
Mathias Hasselmann mathias.hasselm...@gmx.de
Personal Blog: http://taschenorakel.de/mathias/
Openismus GmbH: http://www.openismus.com/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: utf-16 and glib
What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); That's one not needed as strncpy should work. hehe i know but that function it really exist: http://library.gnome.org/devel/glib/unstable/glib-Unicode-Manipulation.html#g-utf8-strncpy It does make sense. strncpy copies N bytes, when what you want to do is copy N characters from a multi-byte encoded string. You don't want to the copy to stop somewhere in the middle of a multi-byte character sequence because the result simply wouldn't make sense. and the macro: gtext* g_text_strncpy (gtext*dest,const gtext*src,gsize n); Because having 2 implementations of a function and having 1 automatically chosen by a pre-processor macro is one of the worst API decisions that Microsoft has ever made. And that's saying something. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_malloc overhead
On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full utf16 and utf8 api in glib and use a macro to work work intermediate string: For example in windows they have this types: LPSTR =char * char * is used for utf-8 AFAIR LPWSTR= utf16windowschar * gunichar2 perhaps in glib we could have utf16 and utf8 in that way or am i wrong? I'm not glib developer. As far as the module of operating on utf-16 strings is proposed I'm not against. However I would prefere to not have 2 entries to each function. Regards Regards. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: utf-16 and glib (was: g_malloc overhead)
On Mon, 2009-01-26 at 22:49 +0100, Martin (OPENGeoMap) wrote: Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full utf16 and utf8 api in glib and use a macro to work work intermediate string: For example in windows they have this types: LPSTR =char * char * is used for utf-8 AFAIR LPWSTR= utf16windowschar * gunichar2 perhaps in glib we could have utf16 and utf8 in that way or am i wrong? I'm not glib developer. As far as the module of operating on utf-16 strings is proposed I'm not against. However I would prefere to not have 2 entries to each function. Hi: What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); That's one not needed as strncpy should work. gunichar2 * g_utf16_strncpy (gunichar2*dest,const gunichar2*src,gsize n); That's kind of support I'm not against. and the macro: gtext* g_text_strncpy (gtext*dest,const gtext*src,gsize n); regards. With the entries - nothing. With macro - it may be just me but I percive it shooting into foot. Just imagine that some header will assume gtext to be utf-8. Other will turn on the macro (or user code) and change it to utf-16. IMHO - having magic switch which might change the ABI is not good. Regards ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: utf-16 and glib
On Mon, 2009-01-26 at 23:01 +0100, Martin (OPENGeoMap) wrote: Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:49 +0100, Martin (OPENGeoMap) wrote: Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full utf16 and utf8 api in glib and use a macro to work work intermediate string: For example in windows they have this types: LPSTR =char * char * is used for utf-8 AFAIR LPWSTR= utf16windowschar * gunichar2 perhaps in glib we could have utf16 and utf8 in that way or am i wrong? I'm not glib developer. As far as the module of operating on utf-16 strings is proposed I'm not against. However I would prefere to not have 2 entries to each function. Hi: What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); That's one not needed as strncpy should work. hehe i know but that function it really exist: http://library.gnome.org/devel/glib/unstable/glib-Unicode-Manipulation.html#g-utf8-strncpy My error. Regards ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: utf-16 and glib
On Mon, 2009-01-26 at 23:48 +0100, Martin (OPENGeoMap) wrote: Dominic Lachowicz escribió: What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); That's one not needed as strncpy should work. hehe i know but that function it really exist: http://library.gnome.org/devel/glib/unstable/glib-Unicode-Manipulation.html#g-utf8-strncpy It does make sense. strncpy copies N bytes, when what you want to do is copy N characters from a multi-byte encoded string. You don't want to the copy to stop somewhere in the middle of a multi-byte character sequence because the result simply wouldn't make sense. and the macro: gtext* g_text_strncpy (gtext*dest,const gtext*src,gsize n); Because having 2 implementations of a function and having 1 automatically chosen by a pre-processor macro is one of the worst API decisions that Microsoft has ever made. And that's saying something. Glib/gtk is full of macros. But how many of them changes the meaning by other 'switch-macro'? I'm nearly sure that all of them evaluate to the same values at each gived platform. I believe que a C compiler is the right place to this kind of unsafe code. What do you mean by 'unsafe'? If the 'unsafe' code is unsafe there is no place to put it. If the 'unsafe' means that the code cannot be verified easily by compiler if it is correct that there is place in C code (or any other). If i want create safe code i have c#,c++, JAVA, D or VALA. Using macros is the only way to ensure intermediate APIs don´t have any overhead. How much is the overhead? How big it is in compare to for example I/O in accessing filesystem, drawing in access to GTK+ or to GC in access to C#/Java? Besides modern GUIs You mean IDE not GUI. have support to understand what we have in a MACRO. Visual c++ have that kind of support. Well. To begin with not everybody uses IDE. I'm happy with emacs. There are people happy with gedit or vim. And, eventually, it doesn't matter what IDE have support to. What programmer have support is the real matter. And - finally - what IDE will do with included header? Regards. Regards ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: utf-16 and glib
Glib/gtk is full of macros. I believe que a C compiler is the right place to this kind of unsafe code. If i want create safe code i have c#,c++, JAVA, D or VALA. Using macros is the only way to ensure intermediate APIs don´t have any overhead. Besides modern GUIs have support to understand what we have in a MACRO. Visual c++ have that kind of support. The argument isn't against macros in general. It's against having macros choose an underlying implementation of a function. As far as I'm aware, this is only done in glib on win32 where filenames are concerned. And this was done because we couldn't change the *fundamentally broken* API due to ABI guarantees (the functions were defined as taking a string in your multi-byte locale. if you upgraded glib to a version that always expected utf8, a lot of existing apps would break due to no fault of their own, which would be bad). That's a completely different use case than yours. And a regrettable one, because everyone agrees that we'd rather not have those macros there if we could have somehow avoided them. You're not supposed to explicitly call the _utf8() version, nor are you supposed to have access to the other deprecated, broken version. Contrast this with all of Microsoft's A/W functions, and you'll see that the situations are completely different. So what you're suggesting is introducing brokenness by design, rather than reluctantly coping with some brokenness of an existing design. Besides, your case is based on some presumed efficiency of using UTF-16, but you have demonstrated no such evidence in your favor, which is unlikely to convince glib's maintainers. The cost of converting a filename from UTF-8 to UTF-16 isn't very high, I'll tell you. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GGtk-CRITICAL **: gtk_label_set_text: assertion `GTK_IS_LABEL (label)` failed
Hello everyone,
I am currently developing my first GTK+ GUI using glade to initiate bus master
DMA. The GUI is set to take DMA transfer specifics (payload, number of
packets, etc). Based on these inputs, I need to set a label or text box
showing the total amount of bytes to be transferred from an add in card to the
chipset.
The GUI loads fine. When the user changes payload, the handler is called and
inside the handler is a call to change the bytes to be transfered label/text
widget. When this call is made, a failure is reported to the console saying it
failed to set the text. I have tried both a textview widget and also a label
widget without success. The main file is a C++ file that will call other C++
functions to run the DMA transfer. I use extern C {} around each handler and
function prototypes and I haven't seen an issue doing this yet.
Below is the code used:
// HANDLER:
void on_wr_tlp_size_changed(GtkComboBox *wr_size, xbmd_app *app) {
wr_tlp_size = gtk_combo_box_get_active_text(wr_size);
gtk_label_set_text(GTK_LABEL(app-write_bytes_to_transfer), TEST);
//this is the line that is failing.
}
Below is more of the code:
// declaring the widget structure so each widget can be accessed within handlers
typedef struct
{
GtkWidget *write_bytes_to_transfer;
} xbmd_app;
int
main (int argc, char *argv[])
{
xbmd_app *app;
/* allocate the memory needed by our TutorialTextEditor struct */
app = g_slice_new (xbmd_app);
/* initialize GTK+ libraries */
gtk_init (argc, argv);
if (init_app (app) == FALSE) return 1; /* error loading UI */
/* show the window */
gtk_widget_show (app-window);
/* enter GTK+ main loop */
gtk_main ();
/* free memory we allocated for TutorialTextEditor struct */
g_slice_free (xbmd_app, app);
return 0;
}
partial code:
gboolean
init_app (xbmd_app *app)
{
app-write_bytes_to_transfer = GTK_WIDGET (gtk_builder_get_object
(builder,
wr_bytes_to_trans));
Any assistance is appreciated.
Thanks,
Jake
_
Windows Live™: E-mail. Chat. Share. Get more ways to connect.
http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_012009
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_malloc overhead
What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); It isn't needed. The nice thing about UTF-8 is that strings in UTF-8 can be handled with normal C str* functions just fine. gunichar2 * g_utf16_strncpy (gunichar2*dest,const gunichar2*src,gsize n); Such a function might well be useful in some circumstances dealing with interoperability or data formats, and I don't oppose adding it to GLib. (Together with g_utf16_strcpy(), g_utf16_strcat() etc.) But I don't think I have ever personally needed such a function in platform-independent GTK code;) (And in code that is inside a Windows ifdef, such functions aren't needed either. The C library on Windows already has wcsncpy(), wcscpy(), wcscat() etc.) and the macro: gtext* g_text_strncpy (gtext*dest,const gtext*src,gsize n); Never, ever. Didn't the previous replies get this across strongly enough? This idiocy is not something we want to copy from the stone age Windows programming style. (In current-day Windows-specific programming in C, I see no reason to uglify your code with those TEXT() macros, TCHAR types, etc. Just use wchar_t for characters, wchar_t literals (L'A'), and wchar_t string literals (LFoo), and call the wide-char versions of C library and Win32 API functions explicitly. Win9x is dead. No reason not to use Unicode explicitly all the time.) (And actually, why would one want to do Windows-specific programming in general in C (or C++) any more... C# and Java are so much nicer. And neither of them has any of this silly TEXT and TCHAR stuff.) --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_malloc overhead
On Thu, 2009-01-29 at 16:51 +0200, Tor Lillqvist wrote: I think strncpy() is one of the few that needs an utf8 equivalent, because a char may span several bytes. Well, he didn't say exactly what semantics he wanted his g_utf8_strncpy() and g_utf16_strncpy() to have. In the UTF-8 case, should the size mean characters or bytes? In the UTF-16 case, characters or 16-bit units? The existing g_utf8_strncpy() has it meaning characters. As such I think the name is bit unfortunate, because of the similarity to strncpy() but then different semantics of the size parameter. Even if the meaning was bytes, I think an utf8-aware function that avoids cutting in the middle of a multibyte char is a plus. Xav ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GGtk-CRITICAL **: gtk_label_set_text: assertion `GTK_IS_LABEL (label)` failed
On Wed, 2009-01-28 at 20:16 -0700, Jacob Wiltgen wrote:
Hello everyone,
I am currently developing my first GTK+ GUI using glade to initiate bus
master DMA. The GUI is set to take DMA transfer specifics (payload, number
of packets, etc). Based on these inputs, I need to set a label or text box
showing the total amount of bytes to be transferred from an add in card to
the chipset.
The GUI loads fine. When the user changes payload, the handler is called and
inside the handler is a call to change the bytes to be transfered label/text
widget. When this call is made, a failure is reported to the console saying
it failed to set the text. I have tried both a textview widget and also a
label widget without success. The main file is a C++ file that will call
other C++ functions to run the DMA transfer. I use extern C {} around each
handler and function prototypes and I haven't seen an issue doing this yet.
Below is the code used:
// HANDLER:
void on_wr_tlp_size_changed(GtkComboBox *wr_size, xbmd_app *app) {
wr_tlp_size = gtk_combo_box_get_active_text(wr_size);
gtk_label_set_text(GTK_LABEL(app-write_bytes_to_transfer), TEST);
//this is the line that is failing.
}
How are you connecting up the handler? I would guess app is not what
you think it is (you could set a breakpoint in gdb, and then know for
sure).
-Larry Reaves
la...@yrral.net
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_malloc overhead
Tor Lillqvist escribió: What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); It isn't needed. The nice thing about UTF-8 is that strings in UTF-8 can be handled with normal C str* functions just fine. this function it really exist :-[ . http://library.gnome.org/devel/glib/unstable/glib-Unicode-Manipulation.html#g-utf8-strncpy n is the number of real chars not the number of bytes. regards. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
