Re: Record/Playback GUI Operations
On 8/25/06, Sai Laxmi K [EMAIL PROTECTED] wrote: Thanks Mr.Vivien, That site was extremely useful. But I have one problem in configuring. I know this query is not relevant to this post, but I'm not able to find any other means to solve this. When I'm configuring Xnee with Cygwin, it's throwing two errors, ERROR Could not locate the needed X11 extensions: RECORD XTest Make sure you have them installed before building Xnee Where can I find these two extensions and how can I include them in my Cygwin. Can you pl. help me. These are the X server extensions, which you need to configure for your X server running on Windows. I don't use windows so I can't help you there, sorry. Maybe try to ask the cygwin guys... Regards, vivien ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Rotate Widgets???
I have an application where i'll need to rotate widgets by 90 degrees. Is there a default way of doing this in GTK. I was looking some of the documentation and didn't come across anything that gave me the impression of being able to accomplish it. Has anybody ever come across this before. Thanks for the help Mike ** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ** ___ 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 engine for Windows version
Hi, everyone! GTK+ implements text layout by using pango and renders text with freetype, in Linux. I dont know if GTK+ for windows still uses pango and freetype. Owing to Uniscribe can do the same thing, do GTK+ for windows use the APIs provided by the Uniscribe to lay out and display text? looking forward to replying. thank you in advance! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib win32 condvar implementation
Alex, I was looking over the gthread win32 implementation today when doing some dbus threading work, and i noticed what i think is a bug: In g_cond_wait_internal() we add the even to the event array in the condvar, then we sleep on it. When we wake up or timeout we then remove the event object from the array... Except we don't, we only do that in the case of a timeout. I really think we always should remove it, and in fact we should reset it always too, in case we got some extra wakeup call inbetween. The technique is as follows: all condition variables are implemented as arrays, containing exactly one entry for every thread, waiting on that condition variable. This entry is a handle to a thread specific win32 Event. In g_cond_wait this entry is added to the array, and in g_cond_signal it is removed, before sending enabling event. Thus g_cond_wait only in case of a timeout has to be remove the entry from the array. This is done for two reasons. Firstly it is faster to remove the entry, while transversing the array. Secondly (and more importantly) it avoids the race condition, where an event is send twice by a g_cond_signal, before g_cond_wait comes around to remove the entry. This event will remain in the event queue and will thus be consumed by the next g_cond_wait, even though no g_cond_signal is called. / Sebastian -- Sebastian Wilhelmi [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: about GTK+ text engine for Windows version
James Ray writes: GTK+ implements text layout by using pango and renders text with freetype, in Linux. I dont know if GTK+ for windows still uses pango and freetype. Pango yes, freetype no. Owing to Uniscribe can do the same thing, do GTK+ for windows use the APIs provided by the Uniscribe to lay out and display text? Yes, Pango uses Uniscribe on Windows. (The above holds for the Win32 backend of Pango. In addition, also the Freetype backend can be built on Windows (and is included in the official binary distribution). It does not Uniscribe. It has exactly the same functionality as on Unix. The Freetype backend isn't used by normal programs, though (not on Unix either), only by programs that specifically code to use it, like GIMP for its text tool.) --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib win32 condvar implementation
On Fri, 2006-08-25 at 10:14 +0200, Sebastian Wilhelmi wrote: Alex, I was looking over the gthread win32 implementation today when doing some dbus threading work, and i noticed what i think is a bug: In g_cond_wait_internal() we add the even to the event array in the condvar, then we sleep on it. When we wake up or timeout we then remove the event object from the array... Except we don't, we only do that in the case of a timeout. I really think we always should remove it, and in fact we should reset it always too, in case we got some extra wakeup call inbetween. The technique is as follows: all condition variables are implemented as arrays, containing exactly one entry for every thread, waiting on that condition variable. This entry is a handle to a thread specific win32 Event. In g_cond_wait this entry is added to the array, and in g_cond_signal it is removed, before sending enabling event. Thus g_cond_wait only in case of a timeout has to be remove the entry from the array. This is done for two reasons. Firstly it is faster to remove the entry, while transversing the array. Secondly (and more importantly) it avoids the race condition, where an event is send twice by a g_cond_signal, before g_cond_wait comes around to remove the entry. This event will remain in the event queue and will thus be consumed by the next g_cond_wait, even though no g_cond_signal is called. I see, i missed the removal in signal. Thanks for explaining. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a gun-slinging Amish paranormal investigator with a robot buddy named Sparky. She's a scantily clad motormouth single mother with the soul of a mighty warrior. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Reverting to non-async file chooser
On Thu, Aug 24, 2006 at 01:02:51AM +0200, Tim Janik wrote:
there are two ways to handle this properly, in a way that doesn't need
to intermix cancellation semantics with closure/memory maintenance.
if your closure references an object that the callback needs, you
can either forcefully keep that object alive through a reference
count until the closures gets freed (which can be early enough with
a high prio idler), or you set a flag in the closure/nullify the
object pointer in the closure once the object becomes invalid, so the
callback can tell it's not supposed to treat the reference as valid.
This gets complicated very quickly, and requires a lot of support code.
it doesn't get complicated at all. you either explicitely ref/unref:
void callback_func (void *data) { g_object_unref (data); }
install_callback (callback_func, g_object_ref (data));
or nullify your pointer and add a check to the callback:
if (!data-owner)
return;
I agree with Tim here; this does not require a lot of support code.
However, as with all things requiring complex reference counting,
getting it right the first time is the hardest part.
A scheme like GnomeVFS's requires no particular intelligence from the
caller.
well, the current scheme does keep it very simple on the caller:
the notification callback is always called and just has the information
on whether the operation was cancelled and if it succeeded or not.
if in any particular case, cancellation also means that the caller
has gone away, and you didn't bother setting up a nullify pointer
handler or ref/unref pair, you can still bail out early in your
callback with:
if (cancelled)
return;
Also, I think having only a single place where the user data of the
callback is freed is a plus of the current design. (Obviously, we lose
this if we don't call the callback after cancellation).
i.e. effectively render your callback inoperable, without
introducing information loss by design.
Caveat: gnome-vfs does not let you cancel the operation of mounting
a drive or volume. So if you cancel the handle from
gtk_file_system_volume_mount(), your callback will not be called,
but the volume *will* be mounted (unless an error occurs during
mounting, of course).
i really consider this scenrio a MUST-NOT-HAPPEN (sorry for the caps ;)
simply because it renders the _combination_ of two _vital_ features
unusable (unreliable), namely cancellation of operations and notification
about the success of operations.
This doesn't make much sense to me; IMHO it's much better the call the
callback and have the cancelled flag set the FALSE in the handle. Since
the volume has been mounted, the cancellation clearly failed. We might
want to choose a different code path in the callback depending on
whether or not the operation was completed/successfully cancelled.
but before some change like this really is decided on, could you please
point out actual _programming_ problems you're having with the
current scheme?
so far, Kris has been working on fixing the remaining issues your other
email pointed out, and hasn't complained about problems with the
cancellation mechanism yet...
I think the current scheme should be good enough to fix the current
issues; I will continue looking it into after the weekend.
regards,
-kris.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Design decisions for GLib and GTK+ on Win32
I think now is the time to decide a couple of issues: - Can the support for Win9x be dropped from GLib and GTK+ HEAD? Note that cairo has never worked on Win9x, so GTK+ has de facto not worked on Win9x since 2.8 anyway. Dropping Win9x support would mean (slightly) cleaner source code in a couple of files. - Can the support for 256-colour (palettized) display mode be dropped from GTK+ HEAD? I have no idea whether it even works currently, and I can't test as my display adapter doesn't even offer a 256-colour mode in Display Properties. If it doesn't work, which I suspect, who is going to fix it? Not I anyway... The support for palettized displays is very ugly and ad-hoc code, it would be a relief to get rid of it. - Can support for the ActiveIMM thingie used to implement IMEs on NT4 (and Win9x) be dropped? Again, I have no idea whether it currently works anyway... (On Windows 2000 and later IMEs are built in, no separate thingie is needed.) - Can Uniscribe be made non-optional in pangowin32? This would just mean dropping some lines of configure.in, and dropping some ifdefs from basic-win32.c. Having it even possible to build pangowin32 without Uniscribe kinda defeats the whole purpose of Pango, doesn't it? My vote is yes on all counts ;) --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Design decisions for GLib and GTK+ on Win32
On 8/25/06, Tor Lillqvist [EMAIL PROTECTED] wrote: I think now is the time to decide a couple of issues: - Can the support for Win9x be dropped from GLib and GTK+ HEAD? Note that cairo has never worked on Win9x, so GTK+ has de facto not worked on Win9x since 2.8 anyway. Dropping Win9x support would mean (slightly) cleaner source code in a couple of files. - Can the support for 256-colour (palettized) display mode be dropped from GTK+ HEAD? I have no idea whether it even works currently, and I can't test as my display adapter doesn't even offer a 256-colour mode in Display Properties. If it doesn't work, which I suspect, who is going to fix it? Not I anyway... The support for palettized displays is very ugly and ad-hoc code, it would be a relief to get rid of it. - Can support for the ActiveIMM thingie used to implement IMEs on NT4 (and Win9x) be dropped? Again, I have no idea whether it currently works anyway... (On Windows 2000 and later IMEs are built in, no separate thingie is needed.) - Can Uniscribe be made non-optional in pangowin32? This would just mean dropping some lines of configure.in, and dropping some ifdefs from basic-win32.c. Having it even possible to build pangowin32 without Uniscribe kinda defeats the whole purpose of Pango, doesn't it? My vote is yes on all counts ;) I don't know much about win32 or GTK+ on that platform, but my uninformed vote is yes on all counts, too. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Design decisions for GLib and GTK+ on Win32
I don't know much about win32 or GTK+ on that platform, but my uninformed vote is yes on all counts, too. Thirded. -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: Design decisions for GLib and GTK+ on Win32
C.J. Adams-Collier writes: Do we have any means by which we can determine what our user base is for each platform? Yes. For GTK+ 2.8, which was the *previous* stable (in a source code maintenance -sense) series, the user percentage on Win9x is zero. (As I said, cairo doesn't work on Win9x, and nobody has bothered enough to fix that, i.e. submit patches.) Those who use GTK+ 2.6 on Win9x can continue to do so, without any chance of bug fixes (from me at least), like they have for a year (since 2.8.0 was released). You've got my vote on all counts, Tor. Let's clean up the codebase. Thanks ;) --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Design decisions for GLib and GTK+ on Win32
On 2006-08-25 11:31:16 PM, Tor Lillqvist wrote: Those who use GTK+ 2.6 on Win9x can continue to do so, without any chance of bug fixes (from me at least), like they have for a year (since 2.8.0 was released). Quite so. I'm all for dropping this stuff from 2.12. Cheers, Ali. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
