using the aplpha channel in linux-fb??
hi there at the moment i am modifying the linux-fb backend to work with an ordinary memory chunk to use the rendered data with OpenGL, the purpose of that is to use gtk as a GUI for games. It works fine so far, except that the black partions of the screen are fully visible, what is not what i want. i want the windows apear above the OpenGL rendered background, the solution seams to be the alpha- channel of the off-screen texture, but even though my fb is 32 bit the aplpha channel if always zero. what i want to know is, how can i force it to be, say 0xff, everywhere a window (or a widget or drawable) is drawn and 0x00 everywhere where no window is. thanks in advance Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_try_new and g_try_new0 + error reporting for g_object_set
As the mail remained uncommented, it has now been posted under http://bugzilla.gnome.org/show_bug.cgi?id=169611 Stefan Stefan Kost wrote: hi hi, is there a reason why we dont have g_try_new and g_try_new0. Why I am asking? We use g_new a lot in our code. Recently we have added a helper method to our unit-tests that goes over gobject properties of a given instance and does read/write checks. This triggered a 'problem'. For one class there is a property denoting the size of a data-structure (number of slots). One can write to this property and then the datastructure will adapt its size. On one hand we do not want to limit the size more than neccesary, so the number of entries is a g_ulong. The unit-testing code now tried to set the property to the largest ulong and this caused it to abort, as g_new0 wasn't be able to allocate that much. Now here would would rather like to notifiy the user that we were not be able to perform that operation, than just aborting. Therefor the need for g_try_new0. The second thing is how does one report that a g_object_set failed? All I can currently think of is an error-property in the object, which the caller can connect a notify handler on and retrieve the GError object in case of a problem. Sorry if this is a bit offtopic, its more a best-practise question... Stefan ___ 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: g_try_new and g_try_new0 + error reporting for g_object_set
On Tue, 2005-03-08 at 16:25 +0100, Stefan Kost wrote: As the mail remained uncommented, it has now been posted under http://bugzilla.gnome.org/show_bug.cgi?id=169611 Stefan Stefan Kost wrote: hi hi, is there a reason why we dont have g_try_new and g_try_new0. g_new and g_new0 are just convenience macros, and glib generally doesn't try to handle oom situations. It should be easy enough to write your own try_new() macro if you need it. Why I am asking? We use g_new a lot in our code. Recently we have added a helper method to our unit-tests that goes over gobject properties of a given instance and does read/write checks. This triggered a 'problem'. For one class there is a property denoting the size of a data-structure (number of slots). One can write to this property and then the datastructure will adapt its size. On one hand we do not want to limit the size more than neccesary, so the number of entries is a g_ulong. The unit-testing code now tried to set the property to the largest ulong and this caused it to abort, as g_new0 wasn't be able to allocate that much. Now here would would rather like to notifiy the user that we were not be able to perform that operation, than just aborting. Therefor the need for g_try_new0. The second thing is how does one report that a g_object_set failed? All I can currently think of is an error-property in the object, which the caller can connect a notify handler on and retrieve the GError object in case of a problem. I think a property setter which can fail is a very bad idea. Properties declare their allowed values, so you can avoid feeding them bad values in the first place. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
scrollwheel kind of widget
A type of widget I'm missing in GTK is something like the scrollbar, but with no particular min/max values. This would be useful for scrolling a canvas with a virtually infinite size, and for zooming (and possibly other things). Irix (which uses something motif-like) has such a widget, see the attached screenshot. (The small button below is used to reset to the default value.) Has this been discussed before? Are there any other (preferred) way to solve the problem with existing widgets? Solutions I have seen (not only in programs using GTK but any toolkit missing this widget) is non optimal in my opinion, and include: * The min/max values are set to the smallest/biggest possible. Thus this might be considered correct, it makes the scrollbar quite useless (since it scrolls the canvas WAY too much). * The min/max values are constantly changed to be slightly smaller/bigger than the smallest/biggest value selected by the user. * The min/max values are constantly changed to reflect a portion of a canvas that contains something interesting. * The scrollbar doesn't reflect the position and size of the canvas but always snaps back to middle position. (This is very similar to how the scrollwheel widget works, but I consider it a misuse of the scrollbar.) * The scrollbar indicates that the whole canvas is visible and only the stepper buttons can be used to scroll the canvas. * There is no scrolling widget at all, and only the cursor keys and/or the mouse can be used to scroll the canvas. attachment: scrollwheel.png___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_file_write()
On Tue, 2005-03-08 at 15:27 -0500, Matthias Clasen wrote: On Tue, 2005-03-08 at 20:49 +0100, Soeren Sandmann wrote: I have put up a new patch at http://www.daimi.au.dk/~sandmann/filewrite2.patch that should take care of most of the comments: - Function is now called g_file_replace(). (I think g_file_replace_contents() suggests that permissions etc. are preserved). I think we've lost having a name that says what the function is for. g_file_write() is a better name than this. Maybe something like g_file_write_entire() but I think that's probably not necessary. Regards, Owen 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
A OverTheSpot patch for gtk 2.4.x and 2.6.x
Hi,
The OverTheSpot mode of XIM is the most common input method for
Chinese/Japanese users.
but it is a pity that gtk2+ library don't support it,
so that all the gtk2+ based applications, like Mozilla, Firefox,
Thunderbird, Gaim, gEdit, NVU...can not support the OverTheSpot mode.
The attached file is a patch of libgtk2.0-0 package to make gtk2+
library support OverTheSpot mode.
It is written by Edward Liu [EMAIL PROTECTED].
After some testing, we feel that this patch is stable enough to update
to the upstream.
Please consider to apply this.
If you're interesting, please read on...
The OverTheSpot mode of XIM will show a floating window sticking with
the cursor position when we are typing.
It is a example of the OverTheSpot mode:
( [CH| ] is the OverTheSpot window )
( | is the place of the cursor. )
I'm typing Chinese... |
[CH|]
I'm typing Chinese... |
[CH|hqi]
[hqi] is the code of the Chinese character.
I'm typing Chinese... (Ch#1)|
[CH|mylm]
[mylm] is the code of another Chinese character.
I'm typing Chinese... (Ch#1)(Ch#2)|
[CH|klg]
[klg] is the code of another Chinese character.
I'm typing Chinese... (Ch#1)(Ch#2)(Ch#3)|
[CH|cnkq]
You can see that the OverTheSpot window is always stick with the cursor
position.
The following is several graphic samples:
http://home.pchome.com.tw/net/tetralet/Linux/Gtk2_OverTheSpot_OpenOffice.png
http://home.pchome.com.tw/net/tetralet/Linux/Gtk2_OverTheSpot_gEdit.png
http://home.pchome.com.tw/net/tetralet/Linux/Firefox-OverTheSpot.png
Unlike OverTheSpot mode,
The Root mode of XIM will show a large, fixed and unmoveable window on
the screen.
It looks a little ugly and sometimes it will disturb the typing if the
input area were under the Root window.
And becouse it is unmoveable, it will be unpleasing if the input area
were too far away from the Root window.
The following is a graphic sample:
http://home.pchome.com.tw/net/tetralet/Linux/Firefox-Root.png
So, We feel that this patch is very important to us.
Please consider to apply this. Thanks.
And, This patch is reported by bugzilla several months ago,
But there was no answer...
Please visit http://bugzilla.gnome.org/show_bug.cgi?id=158678 for more
details. Thanks.
diff -uNr gtk+-2.4.13.orig/modules/input/gtkimcontextxim.c gtk+-2.4.13/modules/input/gtkimcontextxim.c
--- gtk+-2.4.13.orig/modules/input/gtkimcontextxim.c 2004-11-22 05:00:27.0 +0800
+++ gtk+-2.4.13/modules/input/gtkimcontextxim.c 2004-11-22 05:02:51.0 +0800
@@ -179,7 +179,7 @@
XIMPreeditArea | XIMPreeditNothing | XIMPreeditNone)
#define STATUS_MASK (XIMStatusCallbacks | XIMStatusArea | \
XIMStatusNothing | XIMStatusNone)
-#define ALLOWED_MASK (XIMPreeditCallbacks | XIMPreeditNothing | XIMPreeditNone | \
+#define ALLOWED_MASK (XIMPreeditCallbacks | XIMPreeditNothing | XIMPreeditNone | XIMPreeditPosition | \
XIMStatusCallbacks | XIMStatusNothing | XIMStatusNone)
static XIMStyle
@@ -263,6 +263,10 @@
NULL);
if (preedit_style == GTK_IM_PREEDIT_CALLBACK)
info-preedit_style_setting = XIMPreeditCallbacks;
+#if 0
+ else if (preedit_style == GTK_IM_PREEDIT_POSITION)
+info-preedit_style_setting = XIMPreeditpPosition;
+#endif
else if (preedit_style == GTK_IM_PREEDIT_NOTHING)
info-preedit_style_setting = XIMPreeditNothing;
else if (preedit_style == GTK_IM_PREEDIT_NONE)
@@ -806,7 +810,7 @@
return;
spot.x = area-x;
- spot.y = area-y;
+ spot.y = area-y + area-height;
preedit_attr = XVaCreateNestedList (0,
XNSpotLocation, spot,
@@ -1412,6 +1416,36 @@
else
im_style |= XIMStatusNothing;
+ XFontSet fontset = NULL;
+
+ if ((context_xim-im_info-style PREEDIT_MASK) == XIMPreeditPosition) {
+XPoint spot;
+spot.x = spot.y = 0;
+XRectangle rect;
+rect.x = rect.y = 0;
+rect.width = rect.height = 32;
+
+int missing_charsetcount;
+char **missing_charsetlist, *def_string;
+
+fontset = XCreateFontSet(GDK_DISPLAY(),
+ 10x20,10x20,
+ missing_charsetlist,
+ missing_charsetcount,
+ def_string);
+
+list1 = XVaCreateNestedList(0,
+XNArea, rect,
+XNSpotLocation, spot,
+XNForeground, 0,
+XNBackground, 0,
+XNFontSet, fontset,
+ NULL);
+
+im_style = XIMPreeditPosition| XIMStatusNothing;
+name1 = XNPreeditAttributes;
+ }
+
xic = XCreateIC (context_xim-im_info-im,
XNInputStyle, im_style,
XNClientWindow, GDK_DRAWABLE_XID (context_xim-client_window),
___
Re: A OverTheSpot patch for gtk 2.4.x and 2.6.x
I think this is important to Chinese user, I will help you to test this patch with gtk+ 2.6.4, and hope this patch will integrated into next gtk+ release, maybe 2.6.5. Hi, The OverTheSpot mode of XIM is the most common input method for Chinese/Japanese users. but it is a pity that gtk2+ library don't support it, so that all the gtk2+ based applications, like Mozilla, Firefox, Thunderbird, Gaim, gEdit, NVU...can not support the OverTheSpot mode. The attached file is a patch of libgtk2.0-0 package to make gtk2+ library support OverTheSpot mode. It is written by Edward Liu [EMAIL PROTECTED]. After some testing, we feel that this patch is stable enough to update to the upstream. Please consider to apply this. If you're interesting, please read on... The OverTheSpot mode of XIM will show a floating window sticking with the cursor position when we are typing. It is a example of the OverTheSpot mode: ( [CH| ] is the OverTheSpot window ) ( | is the place of the cursor. ) I'm typing Chinese... | [CH|] I'm typing Chinese... | [CH|hqi] [hqi] is the code of the Chinese character. I'm typing Chinese... (Ch#1)| [CH|mylm] [mylm] is the code of another Chinese character. I'm typing Chinese... (Ch#1)(Ch#2)| [CH|klg] [klg] is the code of another Chinese character. I'm typing Chinese... (Ch#1)(Ch#2)(Ch#3)| [CH|cnkq] You can see that the OverTheSpot window is always stick with the cursor position. The following is several graphic samples: http://home.pchome.com.tw/net/tetralet/Linux/Gtk2_OverTheSpot_OpenOffice.png http://home.pchome.com.tw/net/tetralet/Linux/Gtk2_OverTheSpot_gEdit.png http://home.pchome.com.tw/net/tetralet/Linux/Firefox-OverTheSpot.png Unlike OverTheSpot mode, The Root mode of XIM will show a large, fixed and unmoveable window on the screen. It looks a little ugly and sometimes it will disturb the typing if the input area were under the Root window. And becouse it is unmoveable, it will be unpleasing if the input area were too far away from the Root window. The following is a graphic sample: http://home.pchome.com.tw/net/tetralet/Linux/Firefox-Root.png So, We feel that this patch is very important to us. Please consider to apply this. Thanks. And, This patch is reported by bugzilla several months ago, But there was no answer... Please visit http://bugzilla.gnome.org/show_bug.cgi?id=158678 for more details. Thanks. 188--, 5G40 http://www.188.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Scrool to top / buttom using Home / End
Hi, I've experience annoying differences between how Home / End works on Linux and MS Windows. When I have a scrooled window I can go to buttom by pressing End and go to top by pressing Home - when I am using Linux that is! But on Windows it either have no effect to press Home / End or it jumps between first and last tab in a notebook (an ancestor). I this behaviour related to the windows-manager Gnome vs. MS Windows or differences in GTK+? And can I do anything to have the Linux-behaviour on MS Windows too. Linux: Using GTK+-2.4 MS Windows: Using GTK+-2.6 Best regards Egon Andersen -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Gtk -- trying to run pixmap example
ringo schrieb:
I downloaded the tarball but when I tried to do ./configure it gave me a
bunch of errors. It says in the documentation that you don't need to
compile it so I was trying to use it as is, just unzipped. Some of the
other examples compile by just doing a make. Is there something I need
to do since I didn't compile all the source?
Thanks
Ringo
-Original Message-
From: Benjamin [mailto:[EMAIL PROTECTED]
Sent: Monday, March 07, 2005 12:35 AM
To: ringo; gtk-list@gnome.org
Subject: Re: Gtk -- trying to run pixmap example
ringo schrieb:
I downloaded gdk 2.0 and unzipped it. I've been compiling and looking
at
the examples. I just tried to compile the pixmap example and I get an
error: config.h: No such file...
In the main directory that was created when I unzipped I see
config.h.in
and config.h.win32, but no config.h . What do I need to do to fix
this?
Thanks
Ringo
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
first make sure that the config.h of whatever you are compiling is in
the include path - compiler options
second, if the file is not there try to manualy copy the file
config.h.win32 or config.h.in to config.h if you are
using config.h.in (if compiling with automake etc. (./configure)) you
have to replace all sections surounded with '@'
with their coresponding values.
but if all libs have successfully compiled and you are trying to
compile
an example, i guess you are not using the
makefiles shiped with the source-tarball, so you have to modify your
makefile or commandline for your compiler
to include the directory where config.h is in (it depends also who is
trying to include config.h [???]).
the common compiler switch is -I{IncludeDir} - note that you have to
replace {IncludeDir} with the directory where
config.h is in.
hope that helps a bit
Benjamin
if i may may ask: what os you are using
BENJAMIN
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkAlignment makes things smaller, but surrouning don't get bigger
On Mon, 2005-03-07 at 20:45 -0800, Ben Johnson wrote: On Mon, Mar 07, 2005 at 10:56:30PM -0500, Owen Taylor wrote: - If I set expand on *any* widgets to FALSE, they end up too small. Then either add padding to them (or set a minimum size with gtk_widget_set_size_request()). If a widget is to small when not set to expand, then it will be too small when the user resizes the window to it's minimum size. Regards, Owen signature.asc Description: This is a digitally signed message part ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkAlignment makes things smaller, but surrouning don't get bigger
On Tue, Mar 08, 2005 at 12:12:53PM -0500, Owen Taylor wrote: ... - If I set expand on *any* widgets to FALSE, they end up too small. Then either add padding to them (or set a minimum size with gtk_widget_set_size_request()). If a widget is to small when not set to expand, then it will be too small when the user resizes the window to it's minimum size. What is padding? how do I add it? do I add it to buttons or to containers? does it create space between widgets? (sorry for these questions. but, please just give me the name of a function or a property that I can read about.) What I'm shooting for is a constant aspect ratio. I know I can achieve the aspect ratio I'm looking for at my particular screen size using gtk_widget_set_size_request(). I'm not just developing for my screen size though. I would like these buttons to shrink if they need to. maybe there's some mathematical principal I'm missing about the geometry of screen size vs. the number of widgets on a page. maybe my app will be useless on a tiny screen anyway simply because of the the large number of widgets? (...no I don't think I'm missing something I know my app should be able to work on a Zaurus, for instance, because of the pencil tip is small enough to select tiny widgets.) If I use gtk_widget_set_size_request() will it be possible for my app to work on a tiny screen without re-compiling it? Thanks for your patience and help Owen. - Ben ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkAlignment makes things smaller, but surrouning don't get bigger
btw. during our conversation, I've come to believe that the interaction between the GtkAlignment object and the EXPAND and FILL flags isn't working as the documentation implies it should. EXPAND and FILL, if set on all widgets should cause the available space to be consumed. If the size of one or more or those widgets is being constrained by a GtkAlignment, then the widgets that are not constrained should expand *more* to fill the space left open by the GtkAlignment. Isn't that what an alignment object is for? Do you think I should report this as a bug? Regards, - Ben ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkAlignment makes things smaller, but surrouning don't get bigger
On Tue, 2005-03-08 at 12:35 -0800, Ben Johnson wrote: btw. during our conversation, I've come to believe that the interaction between the GtkAlignment object and the EXPAND and FILL flags isn't working as the documentation implies it should. EXPAND and FILL, if set on all widgets should cause the available space to be consumed. If the size of one or more or those widgets is being constrained by a GtkAlignment, then the widgets that are not constrained should expand *more* to fill the space left open by the GtkAlignment. Isn't that what an alignment object is for? Do you think I should report this as a bug? There is no interaction. The GtkAlignment container positions and scales it's child within the space allocated to the GtkAlignment. Owen P.S. It might not hurt to just read the and work through the code for gtkalignment.c size_request() and size_allocate(). You seem to think there is more magic in the GTK+ system than there is. http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtkalignment.c?view=markup) P.P.S. I'm going to drop off this thread now. signature.asc Description: This is a digitally signed message part ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
dateformat
Is there dateformat function in gtk? I have date dd/mm/ and I want to change to /yy/dd Mysql format. thx Hariyanto ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: dateformat
Is there dateformat function in gtk? I have date dd/mm/ and I want
to change to /yy/dd Mysql format.
thx
That would be plain playing
void convert(char *dst, const char *src)
{
dst[0]=src[6];
dst[1]=src[7];
dst[2]=src[8];
dst[3]=src[9];
dst[4]='/';
dst[5]=src[3];
dst[6]=src[4];
dst[7]='/';
dst[8]=src[0];
dst[9]=src[1];
dst[10]=0;
}
Stian
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: propagate_key_event
On Tue, 2005-03-08 at 23:43 +1300, Grant McLean wrote: Anyway, what's that propagate_key_event thing for anyway? The API docs[1] say: | Propagate a key press or release event to the focus widget and up the | focus container chain until a widget handles event. So it does pretty much the opposite of what you want. -- Bye, -Torsten [1] http://developer.gnome.org/doc/API/2.0/gtk/GtkWindow.html#gtk-window-propagate-key-event ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
