about the color
Hi all Now I have a problem, and I hope you tell me, thank you. As followed: #define GTK_RED 0x,0x,0x I don't understand why the red is 0x,0x,0x, but RGB is 255,0,0 So I want to know how gdk parse the color ___ 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 Tue, 2009-01-20 at 09:01 +0100, Martín Vales wrote: BJörn Lindqvist escribió: Actually, a custom allocator could be useful even in the general case. Malloc is a system call and has quite bad performance on certain platforms (windows in particular i think). Something like the gslice allocator could Probably improve performance a bit. gslice i believe use malloc internally. I believe you always need malloc/new-(C/C++) because you depend on ms Windows API. I am not sure if you can build your own malloc because you depend on the operating system. Sure, you must malloc to get new memory, but you can malloc bigger than what you need and hand out the extra memory later at a much lower cost. -Larry la...@yrral.net regards. 2009/1/18, muppet sc...@asofyet.org: On Jan 18, 2009, at 11:43 AM, Martín Vales wrote: What are the advantages of use a glib_mem_vtable ???. I think we have the same malloc function in all operating systems? This vtable allows you to swap in a different allocator with next to no effort. Maybe it has special OOM handling, or uses a special pool or allocation algorithm tuned to your use-case, or does debugging logging work, or whatever. The fact that the default is the same everywhere is a bit beside the point of having the functionality. -- Me: What's that in your mouth? Zella: *swallows laboriously* Nothing. Me: What did you just swallow? Zella: A booger. Me: Baby girl, don't eat boogers. That's gross. Zella: But it was in my nose. ___ 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 ___ 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 Tue, Jan 20, 2009 at 12:48 PM, Larry Reaves la...@yrral.net wrote: On Tue, 2009-01-20 at 09:01 +0100, Martín Vales wrote: BJörn Lindqvist escribió: Actually, a custom allocator could be useful even in the general case. Malloc is a system call and has quite bad performance on certain platforms (windows in particular i think). Something like the gslice allocator could Probably improve performance a bit. gslice i believe use malloc internally. I believe you always need malloc/new-(C/C++) because you depend on ms Windows API. I am not sure if you can build your own malloc because you depend on the operating system. Sure, you must malloc to get new memory, but you can malloc bigger than what you need and hand out the extra memory later at a much lower cost. I recall reading somewhere that mmap can be used to build custom memory allocators. If that's true than one can bypass malloc. I think that you can request memory through mmap by using MAP_ANONYMOUS. Emmanuel Rodriguez ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
typo on gtk.org/download-windows.html
Hi, on the page http://www.gtk.org/download-windows.html stable libpng 1.2.32 is annouced, however, the download links go to version 1.2.34 Bye Felix ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: typo on gtk.org/download-windows.html
on the page http://www.gtk.org/download-windows.html stable libpng 1.2.32 is annouced, however, the download links go to version 1.2.34 Thanks, fixed. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkFileChooser and filter example
GtkWidget * dlg; GtkFileFilter * ff, * ffa; int ret; char * name; dlg = gtk_file_chooser_dialog_new(Select File,GTK_WINDOW(gui.window),GTK_FILE_CHOOSER_ACTION_OPEN,GTK_STOCK_CANCEL,GTK_RESPONSE_CANCEL,GTK_STOCK_OPEN,GTK_RESPONSE_ACCEPT,NULL); ff = gtk_file_filter_new(); gtk_file_filter_set_name(ff,txt); gtk_file_filter_add_pattern(ff,*.txt); gtk_file_chooser_add_filter(GTK_FILE_CHOOSER(dlg),ff); ffa = gtk_file_filter_new(); gtk_file_filter_set_name(ffa,all); gtk_file_filter_add_pattern(ffa,*); gtk_file_chooser_add_filter(GTK_FILE_CHOOSER(dlg),ffa); ret = gtk_dialog_run(GTK_DIALOG(dlg)); -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Centering gtk-status-bar-label
Sorry, forgot Subject, Hello, I use a gtk-status-bar where i want to center the label. Following code worked: gtk_misc_set_alignment(GTK_MISC(GTK_STATUSBAR(gui.statusbar)-label),0.5,0.5); But since I updated to the new gtk-download-bundle (for win32) I get following error-messages: (config.exe:5612): GLib-GObject-WARNING **: invalid cast from `GtkFrame' to `GtkMisc' (config.exe:5612): Gtk-CRITICAL **: gtk_misc_set_alignment: assertion`GTK_IS_MISC (misc)' failed Has somone an idea what could be wrong? regards Arne -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
[no subject]
Hello, I use a gtk-status-bar where i want to center the label. Following code worked: gtk_misc_set_alignment(GTK_MISC(GTK_STATUSBAR(gui.statusbar)-label),0.5,0.5); But since I updated to the new gtk-download-bundle (for win32) I get following error-messages: (config.exe:5612): GLib-GObject-WARNING **: invalid cast from `GtkFrame' to `GtkMisc' (config.exe:5612): Gtk-CRITICAL **: gtk_misc_set_alignment: assertion `GTK_IS_MISC (misc)' failed Has somone an Idea what could be wrong? regards Arne -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Glib::ustring, error while reading an utf-8 encoded file
Hi everybody,
I don't have experience about charset issues so I tried the following to
experiment:
(it's in C++ using glibmm and giomm but I guess the problem is not
related to that, it's just I don't understand something.)
*
#include giomm.h
#include iostream
#include glibmm.h
#include string
int main(int argc, char** argv)
{
Glib::init();
Gio::init();
if(argc!=2) return 1;
//open a file to read
Glib::RefPtrGio::File file=Gio::File::create_for_path(argv[1]);
Glib::RefPtrGio::DataInputStream
fin=Gio::DataInputStream::create(file-read());
std::string line;
//try to read.
try{
int i=1;
while(fin-read_line(line)){
std::couti: as-is: \line\std::endl;
std::couti: through Glib::ustring:
\Glib::ustring(line)\std::endl;
++i;
}
} catch(Glib::ConvertError error){
std::coutstd::endlGlib::ConvertError:
error.what()std::endl;
}
return 0;
}
***
Feading this utf-8 encoded file to the above program:
***
First line: plain text.
deuxième ligne: des accents ici et là...
***
results in:
1: as-is: First line: plain text.
1: through Glib::ustring: First line: plain text.
2: as-is: deuxième ligne: des accents ici et là...
2: through Glib::ustring:
Glib::ConvertError: Invalid byte sequence in conversion input
my locale is using utf-8 (fr_CH).
The question is: How to import the file content in an Glib::ustring when
already knowing its encoding (not necessarily utf-8 though)?
I'm writing an application which will likely have to deal with asian
characters so I need to find out!
Thanks a lot!
Bastien
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
saving window size?
Hi all,
Suppose I have an app, and I would like to save the window size when
when quitting.
This is easy to do if the user selects File-Quit, but what if they
click window-close? By the time you get the destroy signal, the true
width/height values are gone. (You seem to get the default values.)
Is there a resize signal I can listen to?
Here's what I have, in vala:
window.destroy += quitSave;
//quit menu item
Action quit = (Action)builder.get_object(menubar_quit);
quit.activate += (quit) = {quitSave (window);};
...
private void quitSave(Window window)
{
var gc = GConf.Client.get_default ();
int width = 0;
int height = 0;
window.get_size (out width, out height);
if (width 0)
gc.set_int (/apps/moserial/ui/window_width, width);
if (height 0)
gc.set_int (/apps/moserial/ui/window_height, height);
Gtk.main_quit ();
}
Suggestions?
- Mike
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: saving window size?
Look at GtkWidget::delete_event signal.
On Tue, 2009-01-20 at 09:26 -0500, Dr. Michael J. Chudobiak wrote:
Hi all,
Suppose I have an app, and I would like to save the window size when
when quitting.
This is easy to do if the user selects File-Quit, but what if they
click window-close? By the time you get the destroy signal, the true
width/height values are gone. (You seem to get the default values.)
Is there a resize signal I can listen to?
Here's what I have, in vala:
window.destroy += quitSave;
//quit menu item
Action quit = (Action)builder.get_object(menubar_quit);
quit.activate += (quit) = {quitSave (window);};
...
private void quitSave(Window window)
{
var gc = GConf.Client.get_default ();
int width = 0;
int height = 0;
window.get_size (out width, out height);
if (width 0)
gc.set_int (/apps/moserial/ui/window_width, width);
if (height 0)
gc.set_int (/apps/moserial/ui/window_height, height);
Gtk.main_quit ();
}
Suggestions?
- Mike
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
--
Alexander Semenov bohtva...@gmail.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: saving window size?
Hello.
I think you need to save your window's size from within the
delete-event callback. Docs:
http://library.gnome.org/devel/gtk/stable/GtkWidget.html#GtkWidget-delete-event
2009/1/20 Dr. Michael J. Chudobiak m...@avtechpulse.com:
Hi all,
Suppose I have an app, and I would like to save the window size when when
quitting.
This is easy to do if the user selects File-Quit, but what if they click
window-close? By the time you get the destroy signal, the true width/height
values are gone. (You seem to get the default values.)
Is there a resize signal I can listen to?
Here's what I have, in vala:
window.destroy += quitSave;
//quit menu item
Action quit = (Action)builder.get_object(menubar_quit);
quit.activate += (quit) = {quitSave (window);};
...
private void quitSave(Window window)
{
var gc = GConf.Client.get_default ();
int width = 0;
int height = 0;
window.get_size (out width, out height);
if (width 0)
gc.set_int (/apps/moserial/ui/window_width, width);
if (height 0)
gc.set_int (/apps/moserial/ui/window_height, height);
Gtk.main_quit ();
}
Suggestions?
- Mike
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
--
Tadej Borovšak
tadeb...@gmail.com
tadej.borov...@gmail.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: saving window size?
Tadej Borovšak wrote: I think you need to save your window's size from within the delete-event callback. Docs: http://library.gnome.org/devel/gtk/stable/GtkWidget.html#GtkWidget-delete-event Thanks! That did the trick. - Mike ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: saving window size?
On Tue, 2009-01-20 at 09:26 -0500, Dr. Michael J. Chudobiak wrote:
Hi all,
Suppose I have an app, and I would like to save the window size when
when quitting.
This is easy to do if the user selects File-Quit, but what if they
click window-close? By the time you get the destroy signal, the true
width/height values are gone. (You seem to get the default values.)
Is there a resize signal I can listen to?
if you try to save the window size on delete-event or destroy you might
already have lost.
use the ::size-allocate signal on the Window to save the size inside
private data, and the ::window-state-event signal to know whether the
window has been maximized/minimized/fullscreen, etc.:
this.size_allocate += on_size_allocate;
this.window_state_event += on_window_state_event;
this.destroy += on_destroy;
private void on_size_allocate (Allocation alloc) {
this._width = alloc.width;
this._height = alloc.height;
}
private void on_window_state_event (Gdk.EventWindowState event) {
if (event.new_window_state Gdk.WindowState.MAXIMIZED != 0) {
this._is_maximized = true;
}
else {
this._is_maximized = false;
}
}
then use the ::destroy or the ::delete-event signals to save the state
of the window:
private void on_destroy () {
GLib.KeyFile kf = new GLib.KeyFile();
kf.set_integer(WindowState, WindowWidth, this._width);
kf.set_integer(WindowState, WindowHeight, this._height);
kf.set_boolean(WindowState, IsMaximized, this._is_maximized);
buf = kf.to_data();
try {
GLib.FileUtils.set_contents(window-state.cache, buf);
}
catch (Error e) {
warning(Unable to save window state: %s, e.message);
};
}
[BEWARE: this is untested code; it can be regarded as pseudo-code
looking similar to Vala]
Here's what I have, in vala:
window.destroy += quitSave;
//quit menu item
Action quit = (Action)builder.get_object(menubar_quit);
quit.activate += (quit) = {quitSave (window);};
...
private void quitSave(Window window)
{
var gc = GConf.Client.get_default ();
int width = 0;
int height = 0;
window.get_size (out width, out height);
don't *ever* use GConf to store the window size. it's *not* a user
preference, and the GConf can very well be not writable.
use a file inside a directory like the user cache directory as
established by the XDG base dir specification.
ciao,
Emmanuele.
--
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: saving window size?
don't *ever* use GConf to store the window size. it's *not* a user preference, and the GConf can very well be not writable. use a file inside a directory like the user cache directory as established by the XDG base dir specification. Hmm. Could you expand on this (or point me to the docs that explain this more fully)? What is gconf good for, then, exactly? More than one app stores window sizes in gconf... gThumb certainly does. - Mike ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: saving window size?
On Tue, 2009-01-20 at 10:29 -0500, Dr. Michael J. Chudobiak wrote: don't *ever* use GConf to store the window size. it's *not* a user preference, and the GConf can very well be not writable. use a file inside a directory like the user cache directory as established by the XDG base dir specification. Hmm. Could you expand on this (or point me to the docs that explain this more fully)? What is gconf good for, then, exactly? preferences. the size of the window is not an application preference. the sorting order of a list view is a preference; the preferred path for searching for images is a preference; even the default presence status for IM is a preference. the window size is something that can be deleted without losing any meaningful data. also: GConf can be set to be completely read-only (think kiosks or thin clients), which means you *have* to provide fallback code paths to handle the case gracefully. in short: use GConf for user preferences, not for storing random chunks of data. More than one app stores window sizes in gconf... gThumb certainly does. and they are all doing the wrong thing. I'm guilty by association, by the way, because gnome-dictionary uses gconf -- and I should really fix it. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: many buttons, one handler with gtkbuilder
On Tue, Jan 20, 2009 at 7:27 AM, Peter F. Patel-Schneider p...@verizon.net wrote: [...] As I expected, I guess, but it sure would be nice to be able to easily build objects or handlers that have extra information in them in the form of integers or strings. Just being able to initialize the user-data property to a pointer to a string or integer using glade/gtkbuilder would be very useful. Its on my long long todo list, if you want to try your hand at it, I could tell you exactly what has to be done in GtkBuilder and in Glade and coach you through getting your patches reviewed correctly etc. I'm not certain but quite sure Matthias and Johan will not be against the idea (i.e. the GTK+ and GtkBuilder maintainers)... It would not make GNOME 2.26 but could be available in dev releases soon after... Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
compile 2 libs together
Hi, when I'm using allegro, this line is to compile it: gcc -o main main.c `allegro-config --libs` and when I'm using libglade, this line is used: gcc -o main main.c `pkg-config --cflags --libs libglade-2.0` But now I must use allegro and libglade together. How I can compile this together? Thanks ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: compile 2 libs together
Hi, Am Dienstag 20 Januar 2009 schrieb frederico schardong: But now I must use allegro and libglade together. Why not: gcc -o main main.c `pkg-config --cflags --libs libglade-2.0` `allegro-config --libs` Till ___ 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 Jan 18, 2009, at 11:43 AM, Martín Vales wrote: What are the advantages of use a glib_mem_vtable ???. I think we have the same malloc function in all operating systems? This vtable allows you to swap in a different allocator with next to no effort. Maybe it has special OOM handling, or uses a special pool or allocation algorithm tuned to your use-case, or does debugging logging work, or whatever. The fact that the default is the same everywhere is a bit beside the point of having the functionality. -- Me: What's that in your mouth? Zella: *swallows laboriously* Nothing. Me: What did you just swallow? Zella: A booger. Me: Baby girl, don't eat boogers. That's gross. Zella: But it was in my nose. ___ 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
Actually, a custom allocator could be useful even in the general case. Malloc is a system call and has quite bad performance on certain platforms (windows in particular i think). Something like the gslice allocator could Probably improve performance a bit. 2009/1/18, muppet sc...@asofyet.org: On Jan 18, 2009, at 11:43 AM, Martín Vales wrote: What are the advantages of use a glib_mem_vtable ???. I think we have the same malloc function in all operating systems? This vtable allows you to swap in a different allocator with next to no effort. Maybe it has special OOM handling, or uses a special pool or allocation algorithm tuned to your use-case, or does debugging logging work, or whatever. The fact that the default is the same everywhere is a bit beside the point of having the functionality. -- Me: What's that in your mouth? Zella: *swallows laboriously* Nothing. Me: What did you just swallow? Zella: A booger. Me: Baby girl, don't eat boogers. That's gross. Zella: But it was in my nose. ___ gtk-devel-list mailing list gtk-devel-l...@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- mvh Björn ___ 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
BJörn Lindqvist escribió: Actually, a custom allocator could be useful even in the general case. Malloc is a system call and has quite bad performance on certain platforms (windows in particular i think). Something like the gslice allocator could Probably improve performance a bit. gslice i believe use malloc internally. I believe you always need malloc/new-(C/C++) because you depend on ms Windows API. I am not sure if you can build your own malloc because you depend on the operating system. regards. 2009/1/18, muppet sc...@asofyet.org: On Jan 18, 2009, at 11:43 AM, Martín Vales wrote: What are the advantages of use a glib_mem_vtable ???. I think we have the same malloc function in all operating systems? This vtable allows you to swap in a different allocator with next to no effort. Maybe it has special OOM handling, or uses a special pool or allocation algorithm tuned to your use-case, or does debugging logging work, or whatever. The fact that the default is the same everywhere is a bit beside the point of having the functionality. -- Me: What's that in your mouth? Zella: *swallows laboriously* Nothing. Me: What did you just swallow? Zella: A booger. Me: Baby girl, don't eat boogers. That's gross. Zella: But it was in my nose. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bikeshedding the invisible-char
Am Mon, 19 Jan 2009 21:17:50 -0500 schrieb Yu Feng rainwood...@gmail.com: Hi Federico, If I can have a word on this: The big circle is wider than most characters. Compare the following 3 patterns: (10 chars, monospace) ●● •• 1234567890 When people type in a password they don't expect it to look much longer than what has been typed, right? Although the original question has been answered already, for the record, those three examples of yours have all the very same size in my font, which happens to be monospace. Beside that, the user is only ever seeing a number of occurences of a single character. So there is nothing to compare a wider or larger character to. The whole idea behind invisible characters is that they don't reflect the actual password in the first place. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bikeshedding the invisible-char
Am Dienstag, den 20.01.2009, 11:59 +0100 schrieb Christian Dywan: Am Mon, 19 Jan 2009 21:17:50 -0500 schrieb Yu Feng rainwood...@gmail.com: Hi Federico, If I can have a word on this: The big circle is wider than most characters. Compare the following 3 patterns: (10 chars, monospace) ●● •• 1234567890 When people type in a password they don't expect it to look much longer than what has been typed, right? Although the original question has been answered already, for the record, those three examples of yours have all the very same size in my font, which happens to be monospace. Beside that, the user is only ever seeing a number of occurences of a single character. So there is nothing to compare a wider or larger character to. The whole idea behind invisible characters is that they don't reflect the actual password in the first place. I wonder if the default password character shouldn't be a style property. In that case you could use big circles for the default theme, small circles for monospaced themes and pumpkins or skulls for Halloween themes. Ciao, Mathias -- Mathias Hasselmann mathias.hasselm...@gmx.de Personal Blog: http://taschenorakel.de/mathias/ Openismus GmbH: http://www.openismus.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
