Background color problem with Gtk+ 3.6

2013-06-20 Thread Mark Leisher
style context or GDK cairo call somewhere. I checked the widget sources in Gtk+ 3.6.4 and don't see anything missing from my own code, but I may not have looked carefully enough. -- Mark Leisher ___ gtk-devel-list mailing list gtk-devel-list@gnome

Re: __uint128_t support in gobject introspection

2013-05-07 Thread Mark Salter
On Tue, 2013-05-07 at 09:14 -0400, Colin Walters wrote: > On Mon, 2013-05-06 at 16:02 -0400, Mark Salter wrote: > > > That got rid of the error messages I was seeing. > > Found a reviewer; merged to master. Feel free to backport to the Fedora > packages if you want. I do

Re: __uint128_t support in gobject introspection

2013-05-06 Thread Mark Salter
On Sun, 2013-05-05 at 14:56 -0400, Colin Walters wrote: > On Thu, 2013-05-02 at 14:00 -0400, Mark Salter wrote: > > > > > I think ignoring it would probably be fine. We're just building existing > > code. No new APIs. > > Can you try > > https://

Re: __uint128_t support in gobject introspection

2013-05-05 Thread Mark Salter
On Sun, 2013-05-05 at 14:56 -0400, Colin Walters wrote: > On Thu, 2013-05-02 at 14:00 -0400, Mark Salter wrote: > > > > > I think ignoring it would probably be fine. We're just building existing > > code. No new APIs. > > Can you try > > https://

Re: __uint128_t support in gobject introspection

2013-05-02 Thread Mark Salter
On Thu, 2013-05-02 at 10:41 -0400, Colin Walters wrote: > Hi Mark, > > On Mon, 2013-04-29 at 12:43 -0400, Mark Salter wrote: > > I ran into an issue in gobject-introspection while bootstrapping fedora > > packages for AArch64. I was able to build gobject-introspection bu

__uint128_t support in gobject introspection

2013-05-01 Thread Mark Salter
t' So, aarch64 gcc has a builtin __uint128_t which the kernel exposes in some of its headers. It seems like gobject-introspection about this type. Am I missing anything? It sees like an easy enough thing to do from a quick glance at the code, but I could just be naive about it. --Mark __

__uint128_t support in gobject introspection

2013-04-30 Thread Mark Salter
this type. From a quick glance at the code, it sees like an easy enough thing to do. Am I missing anything? --Mark ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Why keysym constants in gdk/gdkkeysyms.h are defined as macros, not as an enum?

2012-06-27 Thread Mark Vender
On 06/27/2012 03:35 AM, Bastien Nocera wrote: On 26 Jun 2012, at 22:56, Mark Vender wrote: which has no chance of negative effects. Even if we add values, they are still stored in an int, that is, GdkKeySym is never used. If its definition is public, it will be used. We can use an unnamed

Re: Why keysym constants in gdk/gdkkeysyms.h are defined as macros, not as an enum?

2012-06-27 Thread Mark Vender
ost in the mailing list. Cheers, Mark [1] - https://bugzilla.gnome.org/show_bug.cgi?id=678975 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Why keysym constants in gdk/gdkkeysyms.h are defined as macros, not as an enum?

2012-06-26 Thread Mark Vender
On 06/26/2012 07:57 PM, Matthias Clasen wrote: On Tue, Jun 26, 2012 at 11:10 AM, Mark Vender wrote: It's impossible for an application to break when enum values are added. They end up as integers within the code anyway and unless their values change, API/ABI stays the same. I could

Re: Why keysym constants in gdk/gdkkeysyms.h are defined as macros, not as an enum?

2012-06-26 Thread Mark Vender
On 06/26/2012 09:22 PM, Christophe Fergeau wrote: 2012/6/26 Mark Vender : Well, C doesn't actually have such restriction. Yes and no, if you assign an integer to a variable of an enum type, and if this integer is not one of the value defined for this enum type, then this is unde

Re: Why keysym constants in gdk/gdkkeysyms.h are defined as macros, not as an enum?

2012-06-26 Thread Mark Vender
y and unless their values change, API/ABI stays the same. Cheers, Mark ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Why keysym constants in gdk/gdkkeysyms.h are defined as macros, not as an enum?

2012-06-26 Thread Mark Vender
enums. An enum offers better scoping and would be easier to wrap on the C++ side. If there's support, I could prepare a patch that converts the keysym macros to an enum. From the user's point of view enum and macro constants are equivalent, so there's no need to wait for an API/

[patch] stray commas

2010-06-10 Thread Mark Brand
Hi, File gio/gioenums.h b/gio/gioenums.h in glib-2.25.7.tar.bz2 has some stray commas at the end of enums that gcc 4.5 does not like. This patch removes them. -Mark diff -urN a/gio/gioenums.h b/gio/gioenums.h --- a/gio/gioenums.h 2010-05-24 18:39:22.0 +0200 +++ b/gio/gioenums.h

[patch] stray commas

2010-06-05 Thread Mark Brand
Hi, File gio/gioenums.h b/gio/gioenums.h in glib-2.25.7.tar.bz2 has some stray commas at the end of enums that gcc 4.5 does not like. This patch removes them. -Mark diff -urN a/gio/gioenums.h b/gio/gioenums.h --- a/gio/gioenums.h 2010-05-24 18:39:22.0 +0200 +++ b/gio/gioenums.h

Re: gthread: how many cores do I have?

2010-04-04 Thread Mark Mielke
ze much of the CPU, would probably use the first count, whereas something doing heavy I/O and quick transfers of data from one thread to the other might choose the latter count. Cheers, mark ___ gtk-devel-list mailing list gtk-devel-list@gnom

[PATCH] glib-2.23.6 gkeyfile.c whitespaces.

2010-03-23 Thread Mark Ellzey Thomas
the end of the value then do error checking. Thanks for the project! ~Mark gkeyfile.c.diff Description: Binary data ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-11-18 Thread Mark
On Sat, Nov 14, 2009 at 5:18 PM, Mark wrote: > On Mon, Oct 5, 2009 at 3:05 PM, Mark wrote: >> On Mon, Oct 5, 2009 at 3:26 PM, Dr. Michael J. Chudobiak >> wrote: >>> On 10/03/2009 02:08 PM, Mark wrote: >>>>> >>>>> So what's the conclus

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-11-14 Thread Mark
On Mon, Oct 5, 2009 at 3:05 PM, Mark wrote: > On Mon, Oct 5, 2009 at 3:26 PM, Dr. Michael J. Chudobiak > wrote: >> On 10/03/2009 02:08 PM, Mark wrote: >>>> >>>> So what's the conclusion? The existing Nautilus code is OK, except that >>>> i

Re: Thumbnailing service project; opinions, suggestions?

2009-10-20 Thread Mark
On Wed, Oct 21, 2009 at 1:39 AM, Andrew Cowie wrote: > Mark, > > On Mon, 2009-10-19 at 16:32 +0200, Mark wrote: >> on school i study ... >> So this project, described in depth below... > > Keep in mind that contribution to an open source project doesn't have to &g

Re: Thumbnailing service project; opinions, suggestions?

2009-10-20 Thread Mark
was not at all my intend to somehow just get my name on there. Don't get me wrong. I can provide myself with all those requests bit not on the gnome site and i would have preferred that. On Tue, Oct 20, 2009 at 6:11 PM, Cosimo Cecchi wrote: > Hi Mark, > > On Tue, 2009-10-20 at 16:34

Re: Thumbnailing service project; opinions, suggestions?

2009-10-20 Thread Mark
>> I do miss some vital parts: >> - Designing the daemon and plugin architecture >> - Making those 2 >> >> That's what i see missing now but i probably missed a few other parts. > > > If you want to make a functional analysis of Tumbler, then go ahead. If > you want to draw cute UML diagrams with t

Re: Thumbnailing service project; opinions, suggestions?

2009-10-20 Thread Mark
On Tue, Oct 20, 2009 at 1:08 PM, Philip Van Hoof wrote: > On Mon, 2009-10-19 at 21:35 +0200, Mark wrote: > >> For Jannis and Philip, >> Nice tumbler talk but could you two make suggestions for my project? ^_^ > > As I already wrote: > > A PDF thumbnailer th

Re: Thumbnailing service project; opinions, suggestions?

2009-10-19 Thread Mark
On Tue, Oct 20, 2009 at 1:18 AM, Shawn Bakhtiar wrote: > Hi Mark, > Hi > > It sounds like you are going to do, what you are going to do, and though it > is of great benefit to you, I suppose I would ask the questions (in > agreement with the last post on this): > > 1) h

Re: Thumbnailing service project; opinions, suggestions?

2009-10-19 Thread Mark
ubmitted in "quality". For Jannis and Philip, Nice tumbler talk but could you two make suggestions for my project? ^_^ On Mon, Oct 19, 2009 at 5:20 PM, Rob Taylor wrote: > Hi Mark, > > We already have a thumbnailing service that is only just now starting to > be used. A complete r

Thumbnailing service project; opinions, suggestions?

2009-10-19 Thread Mark
hope some people could post their opinions about this, where can more optimizing things be done that fall in this scope, did i miss features for the thumbnialing service? etc.. etc.. Your feedback would be greatly appreciated. Thanx a lot for reading this long mail, Mark ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Persistent Binary Search Trees

2009-10-05 Thread Mark
On Mon, Oct 5, 2009 at 3:05 PM, Dana Jansens wrote: > Hello, > > I am interested in contributing code for persistent binary search > trees to the GLib project.  This would actually count as credit > towards a grad level data structures class for me, but I have a lot of > experience working with GL

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-10-05 Thread Mark
On Mon, Oct 5, 2009 at 3:26 PM, Dr. Michael J. Chudobiak wrote: > On 10/03/2009 02:08 PM, Mark wrote: >>> >>> So what's the conclusion? The existing Nautilus code is OK, except that >>> it >>> should be threaded? >> >> That sounds like a goo

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-10-03 Thread Mark
On Fri, Oct 2, 2009 at 2:11 PM, Dr. Michael J. Chudobiak wrote: >> The one with just 21 seconds is where all my images are in cache. >> That's also where all my cores are working at 100% >> The other thread benchmark (70 seconds) vauses all cores to work at ~40% > > So what's the conclusion? The e

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-10-01 Thread Mark
On Thu, Oct 1, 2009 at 4:31 PM, Ross Burton wrote: > On Thu, 2009-10-01 at 16:00 +0200, Petr Tomasek wrote: >> On Wed, Sep 30, 2009 at 05:51:56PM +0100, Ross Burton wrote: >> > On Wed, 2009-09-30 at 12:32 -0400, David Zeuthen wrote: >> > > (Btw, this infrastructure is not specific to the gphoto2:/

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-09-30 Thread Mark
On Wed, Sep 30, 2009 at 8:13 PM, Ross Burton wrote: > On Wed, 2009-09-30 at 13:06 -0400, David Zeuthen wrote: >> No, it's actually a great example. >> >> The way it works is that a GVfs backend can set the preview::icon file >> attribute (which is a GIcon) [1] to whatever it wants. In GVfs we have

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-09-30 Thread Mark
On Wed, Sep 30, 2009 at 4:58 PM, Alexander Larsson wrote: > On Wed, 2009-09-30 at 16:07 +0200, Alexander Larsson wrote: >> On Wed, 2009-09-30 at 15:27 +0200, Philip Van Hoof wrote: >> > On Fri, 2009-08-28 at 22:11 +0200, Mark wrote: >> > >> > > >>

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-09-30 Thread Mark
On Wed, Sep 30, 2009 at 3:27 PM, Philip Van Hoof wrote: > On Fri, 2009-08-28 at 22:11 +0200, Mark wrote: > >> >> Now for the results: >> >> Glib >> -- >> 1927 images thumbnailed in 2.29 minutes. That is roughly 0.07 sec

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-09-30 Thread Mark
On Wed, Sep 30, 2009 at 12:42 PM, Alexander Larsson wrote: > On Wed, 2009-09-30 at 12:36 +0200, Mark wrote: >> On Wed, Sep 30, 2009 at 11:46 AM, Alexander Larsson wrote: >> > On Tue, 2009-09-29 at 22:59 +0200, Mark wrote: >> > >> >> hehe that was the idea i

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-09-30 Thread Mark
On Wed, Sep 30, 2009 at 11:46 AM, Alexander Larsson wrote: > On Tue, 2009-09-29 at 22:59 +0200, Mark wrote: > >> hehe that was the idea indeed ^_^ and i will continue with that. >> I will test the large factors tomorrow. >> >> For now i'm happy with 100% cpu usa

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-09-29 Thread Mark
On Tue, Sep 29, 2009 at 9:46 PM, Dr. Michael J. Chudobiak wrote: > On 09/29/2009 12:00 PM, Mark wrote: >> >> Well, the benchmarks ran above are resizing 1927 wallpaper sized >> images to a max width or height of 200 and that function clearly >> loses. >> The sol

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-09-29 Thread Mark
On Tue, Sep 29, 2009 at 6:00 PM, Mark wrote: > On Mon, Aug 31, 2009 at 4:06 PM, Dr. Michael J. Chudobiak > wrote: >> On 08/31/2009 09:03 AM, jcup...@gmail.com wrote: >>>>> >>>>> a very quick load-at-1/8th-size read where it just decompresses enough &

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-09-29 Thread Mark
On Mon, Aug 31, 2009 at 4:06 PM, Dr. Michael J. Chudobiak wrote: > On 08/31/2009 09:03 AM, jcup...@gmail.com wrote: a very quick load-at-1/8th-size read where it just decompresses enough to be able to get the DC component of each 8x8 block. If you use libjpeg like this you can

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-08-30 Thread Mark
On Sun, Aug 30, 2009 at 3:51 PM, wrote: > 2009/8/28 Mark : >> static GdkPixbuf * >> scale_pixbuf_preserve_aspect_ratio (GdkPixbuf *pixbuf, >>                                    gint size, >>                                    GdkInterpType interp) > > One more

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-08-29 Thread Mark
, 0x7fcaa64de140, 0x69525f7974696e61) = 0x7a4b2f60 > 1251553123.625977 _ZNSsD1Ev(0x7a4b2fa0, 0, 0x786c50, 0x5cf210, > 0x69525f7974696e61) = 0x782018 > > I have no clue what is going on in those _Z* functions.. what are those? > > 1251553123.626120 gdk_pixbuf_ne

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-08-29 Thread Mark
reamIT_T0_ES7_RKSbIS4_S5_T1_E(0x7a4b2df0, 0x701ac0, 88, 88, 0x2f6e6f6974616d69) = 0x7a4b2df0 1251553123.625878 _ZNKSt18basic_stringstreamIcSt11char_traitsIcESaIcEE3strEv(0x7a4b2fa0, 0x7a4b2de0, 0x7a4b2de0, 88, 0x5f7974696e616d75) = 0x7a4b2fa0 1251553123.625929 _ZNSsaSERKSs(0x

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-08-28 Thread Mark
On Sat, Aug 29, 2009 at 1:04 AM, Christian Hergert wrote: > >> On Fri, Aug 28, 2009 at 11:49 PM, Christian Hergert >>  wrote: >>> >>> Hi, >>> >>> What you mentioned is good information to start hunting.  Was the CPU >>> time >>> related to IO wait at all?  Always get accurate numbers before >>> per

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-08-28 Thread Mark
On Fri, Aug 28, 2009 at 11:38 PM, David Zeuthen wrote: > On Fri, 2009-08-28 at 23:15 +0200, Mark wrote: >> I haven't done io profiling but i did calculate the disc usage for >> those 1927 files. and every benchmark was WAY below what my hdd could >> handle (Spinpoint F1

Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-08-28 Thread Mark
just thumbnails might be a good idea. > > Cheers, > > -- Christian > > Mark wrote: >> >>  is there anyone here that has experienced with this? is there >> anyone i an work with on this? actually anyone that could help me >> through this? i'm brand new

Speeding up thumbnail generation (like multi threaded). Thoughts please.

2009-08-28 Thread Mark
that could help me through this? i'm brand new in glib and new to programming in general. I would like to give this a try but i'm afraid i can't do this alone. So any information about this, help and thoughts would be nice. Mark. ___ gt

GtkEntry and transparency (for GTK 3)

2009-08-17 Thread Mark
i knew nothing about gtk and right now i only know a few minor things. So those patches are probably useless. Thanx, Mark ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Performance issue when trashing files (backtraced to fsync)

2009-08-11 Thread Mark
On Tue, Aug 11, 2009 at 4:46 PM, Alexander Larsson wrote: > On Tue, 2009-08-11 at 16:09 +0200, Mark wrote: >> Hi, >> >> A few days ago i deleted thousands of files with just nautilus. That >> went fine but horribly slow. doing the same with the rm command was >> w

Performance issue when trashing files (backtraced to fsync)

2009-08-11 Thread Mark
g_strerror (save_errno)); g_unlink (tmp_name); goto out; } #endif So, the problem is outlined here. Now what would be a solution for this issue? Thanx, Mark. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib uses wrong prefix for base-2 units

2009-06-03 Thread Mark Mielke
erson would correctly and confidently tell me what the difference between K and Ki is. I'm a techie, and it throws *me* for a loop. "Correct"? Not at all. It's just one group of people trying to resolve an ambiguity by pushing an idea on everybody else. Has it been embr

Re: Review of gnio, round 1

2009-04-27 Thread Mark Mielke
caller, or don't use up file descriptors, but require the caller to be written sensibly. Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Review of gnio, round 1

2009-04-27 Thread Mark Mielke
a block as unlikely might limit it's ability to reorder your code to best advantage. Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: fsync in glib/gio

2009-03-15 Thread Mark Mielke
oach would be to change the spec. Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: fsync in glib/gio

2009-03-15 Thread Mark Mielke
Stef Walter wrote: Mark Mielke wrote: I think fsync() is absolutely necessary to be explicit in this situation, because the application needs to assert that all data is written *before* using rename to perform the atomic-change-in-place effect. I think that anybody who thinks fsync() is

Re: fsync in glib/gio

2009-03-14 Thread Mark Mielke
gtk-devel-list. At best, it's a legitimate rant. At worst, it's an ignorant rant. In any case, it's a rant. Fix glib/gio for the rename atomic change-in-place case specifically. Everybody is happy from a glib/gio perspective. If "thousands of other applications" are

Re: fsync in glib/gio

2009-03-14 Thread Mark Mielke
Alexander Larsson wrote: On Sat, 2009-03-14 at 13:38 -0400, Mark Mielke wrote: Should sed -i use fsync()? If it is promising atomic-change-in-place, then it certainly should. This is the same kind of reasoning that says its ok to do something because its specified by posix. If its not

Re: fsync in glib/gio

2009-03-14 Thread Mark Mielke
. The only way to guarantee the operation is safe is using fsync() before close(). Relying on the file system to guess your intent is unreasonable. Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: fsync in glib/gio

2009-03-14 Thread Mark Mielke
e is room for it to take this direction - but the expectation that is must is unrealistic. If a lot of code out there happens to be buggy (for example - close()/rename() from atomic-change-in-place), then the file system can try to work around these bugs, but I think it's wr

Re: fsync in glib/gio

2009-03-13 Thread Mark Mielke
Mark Mielke wrote: Putting fsync() on close() is a hack. Hmm - Looking at the patch, I don't see it doing fsync() on close() - I should have read from the beginning instead of reacting to the one person calling the file system semantics broken. :-) Definitely - any file system opera

Re: fsync in glib/gio

2009-03-13 Thread Mark Mielke
disk before the application continues to do another write(). glib/gio cannot guess where these points are. Putting fsync() on close() is a hack. Just my opinion. :-) Cheers, mark -- Mark Mielke ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: DBus IDL (Was Re: GLib plans for the next cycle)

2009-03-03 Thread Mark Doffman
fix that on their own. > I am actually re-using something that already exists. The struct-like syntax for message-passing interfaces is almost exactly the same as google protocol buffers language. http://code.google.com/apis/protocolbuffers/docs/proto.html#simple Thanks Mark ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: DBus IDL (Was Re: GLib plans for the next cycle)

2009-03-02 Thread Mark Doffman
rly sure that what I'm doing here is correct. But I'll admit it does move away from the syntax comfort zone. There really isn't that much to learn with an IDL, its not a programming language, so people should be able to pick up the one moderately new thing fairly quickly. > >

DBus IDL (Was Re: GLib plans for the next cycle)

2009-03-02 Thread Mark Doffman
Hi Havoc, Thanks for the reply. I have also changed the subject of this which I should have done in the initial e-mail. > Hi, > > On Mon, Mar 2, 2009 at 3:40 AM, Mark Doffman > wrote: >> Both the throws and reply clauses are optional, but if a method does not >> have a

Re: GLib plans for the next cycle

2009-03-02 Thread Mark Doffman
are difficult because the method of transport for the properties is unknown. (Telepathy uses a different properties interface I believe) The default should be org.freedesktop.DBus.Properties but perhaps there needs to be an extension to specify the underlying interface. Thanks Mark ___

Re: GLib plans for the next cycle

2009-03-02 Thread Mark Doffman
Messdl? (Message description language) Something more inventive anyone? > > Anyways I am really glad that someone is looking into this, but I also hope > that we end up with only one IDL and not N > 1. > Thanks Mark ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib plans for the next cycle

2009-03-02 Thread Mark Doffman
ll make it easier to create new 'C' bindings for AT-SPI D-Bus. I'd like to know if there is any information missing that would make this difficult. There doesn't need to be one IDL to rule them all, people designing D-Bus specifications

Re: my ongoing fantasy of garbage collected C programming

2008-08-06 Thread Mark Mielke
eve this is the default Boehm GC mode?) will not have any problem with the above. I foresee limited benefit of GC for Gtk+/Glib at this time, as many of the data structures are reference counted today, and reference counting PLUS garbage collection is certainly slower than reference counting

Re: GHashTable and const

2008-07-04 Thread Mark Mielke
hoice was wrong. But, it's water under the bridge. Life goes on. The question is now whether it's worth it to change - and I suspect the answer is no. Cheers, mark -- Mark Mielke <[EMAIL PROTECTED]> ___ gtk-devel-list mailin

Re: GHashTable and const

2008-07-03 Thread Mark Mielke
a gconst that is defined to nothing on systems that do not support it, or for compatibility. Not saying it should be done or not - but if it is done, this isn't the first time in history this compatibility issue has been faced. Cheers, mark -- Mark Mielke <

Re: GHashTable and const

2008-07-03 Thread Mark Mielke
ge does not allow for a direct match between intent and actual implementation. :-) But, this is probably a waste of a thread as glib has done what glib has done. Cheers, mark -- Mark Mielke <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-de

Re: Moving "Open with" to the platform

2008-03-24 Thread Mark Seaborn
lls had a built-in timeout, and I couldn't work out how to switch it off. There's a risk that this could leave a dialog unuseful after the timeout has expired, although "Open with" would probably be a send-only operation. Mark ___ gtk

Re: Move to LGPL3

2008-03-19 Thread Mark Mielke
Paul Pogonyshev wrote: Mark Mielke wrote: If I choose to download Oracle, and connect a GPL product to Oracle *without redistribution*, there is nothing the FSF can do to stop me. They actually don't. GPL applies only if you distribute modified or unmodified result. At hom

Re: Move to LGPL3

2008-03-19 Thread Mark Mielke
Mark Mielke wrote: > If I choose to download Oracle, and connect a GPL product to Oracle > *without redistribution*, there is nothing the FSF can do to stop me. I should qualify - I went down a path I thought Dominic was leading but away from the Gtk topic. The above is grey in terms of w

Re: Move to LGPL3

2008-03-19 Thread Mark Mielke
Dominic Lachowicz wrote: On Tue, Mar 18, 2008 at 8:46 PM, Mark Mielke <[EMAIL PROTECTED]> wrote: Jean Bréfort wrote: > Windows API (and may be DirectX) is a special case, because you can't > write a Windows program without using it. > It's not a special ca

Re: Move to LGPL3

2008-03-18 Thread Mark Mielke
options, and effort is made to distance oneself from any conclusion that the product might require the use of a GPL library or that the product will function better with the GPL library. Messy. Anyways - I hope this helps. Cheers, mark -- Mark Mielke <[EMAIL PROTECTED]> _

Re: Move to LGPL3

2008-03-18 Thread Mark Mielke
ates. If the v2 programs stick to v2 interfaces, there is no issue. > 3. Companies are vary of GPLv3. It took a long time to begin to > understand GPLv2, GPLv3 is still relatively more intimidating. > The GPL has always been scary. The people who were ever comfortab

Re: gtk_show_help and gtk_show_url

2007-10-08 Thread Mark McLoughlin
gnome and gnome-vfs only exists so libgnomeui could have the on_screen() versions. So ... gtk+ would need only need the on_screen() versions. Cheers, Mark. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/lis

Re: Performance implications of GRegex structure

2007-03-17 Thread mark
; ... } g_matcher_free(record_matcher); } g_regexp_free(section_regexp); The above would match again: Hyperlinks: hlink-selector "..." -> "..." hlink-selector ... Notice all the st

Re: Performance implications of GRegex structure

2007-03-16 Thread mark
vailable as: while ($scalar =~ /(pattern)/g) { ... each match ... } With a Matcher object, the same can be accomplished in a thread-safe manner. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . .

Re: Performance implications of GRegex structure

2007-03-16 Thread mark
completion. Steady state is reached. In your no-brainer example, you have assumed that there are only 5 common RE's in use. If there were 6 that cycled, it would break. Having each Pattern have it's own pool, allows for

Re: Performance implications of GRegex structure

2007-03-16 Thread mark
ct the regex, there will be a memory > leak. > B) GRegex has internal state that is modified by g_regex_match() Agree with both. > None of the examples I shown used global constructors. Correct. Overhead is only on first use. Dave: Your detector is not sens

Re: Performance implications of GRegex structure

2007-03-15 Thread mark
On Thu, Mar 15, 2007 at 10:56:57AM -0400, Owen Taylor wrote: > The compiled form of a regular expression is not altered during matching, > so the same compiled pattern can safely be used by several threads at once. > ... > Well, I could imagine (maybe, barely) that someone could show me numbers >

Need a little guidance with signals

2007-03-07 Thread Mark Richardson
ke this... Gtk-WARNING **: unable to find signal handler for object(CustomWidget:0x8b5e4b0) with func(0x81a1618) and data (0xbffeca30) I thought I understood how signals work, but I now I know that I don't have a clue. Thanks for any help, Mark -

Re: GTK+ 2.10.7 released

2007-01-06 Thread mark
to be humorous but serious. Usually my mailbox is pretty quiet about GTK+. Not so in the last few days... :-) Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neig

Re: Pluggable widgets II

2006-12-20 Thread Mark McLoughlin
On Wed, 2006-12-20 at 15:04 +0100, Tim Janik wrote: > On Wed, 20 Dec 2006, Mark McLoughlin wrote: > > With this API the vendor would need to have a gtk module or library > > especially for the gnome-panel in order to appoint a new implementation > > of PanelMenu. >

Re: Pluggable widgets II

2006-12-20 Thread Mark McLoughlin
On Wed, 2006-12-20 at 10:46 +0100, Tim Janik wrote: > On Wed, 20 Dec 2006, Mark McLoughlin wrote: > > Whichever it is, I'm wondering about things like VinoUrl - i.e. an > > application derived widget. Should it be expected that a plugged-in > > re-implementation of G

Re: Pluggable widgets II

2006-12-20 Thread Mark McLoughlin
On Wed, 2006-12-20 at 10:22 +0100, Tim Janik wrote: > On Wed, 20 Dec 2006, Mark McLoughlin wrote: > > - How does this work for application derived types? > > > >e.g. if vino derives from GtkLabel to make a label which looks like > >a clickable URL, then even

Re: Pluggable widgets II

2006-12-20 Thread Mark McLoughlin
e derived gtype Thanks, Mark. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Epoll in Glib

2006-12-17 Thread mark
le descriptors that are monitoring, what would be nice about using a non-portable feature in a portable library? I assume the GDK/GTK input loop could be modified to support epoll. I find myself doubting that the change would be worth it... Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTEC

Re: Warnings/Errors during Threaded Execution

2006-11-30 Thread Mark Richardson
I'm guessing that you're accessing some widgets in a separate thread (or in your callbacks). Whenever you do this, you need to lock the widgets so that you're not modifying them while they are trying to be drawn. So in a callback, you need gdk_threads_leave(); // the code that is needed f

Re: GEvent - Proposal for a new threading structure for GLib

2006-11-17 Thread mark
es the flag, and the other person wakes up because the flag is raised. There are a few ways to do this... Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_

Re: Is GStringChunk still useful?

2006-11-06 Thread mark
x27;s garbage collector, where the garbage collection does not occur until the end. It's an excellent idea in my opinion, and I would suggest that GStringChunk could be extended to better support this concept. Why only add strings to the chunk? Why not add data structures, appropriately alig

Re: Is GStringChunk still useful?

2006-11-06 Thread mark
Space is probably irrelevant in most applications. Allocation time, especially in a multi-threaded context with synchronization on the free memory pools, is not irrelevant. > I think we want what I describe above, or nothing at all. I think you should prove your first claim and go on

Re: custom widget

2006-09-27 Thread Mark Richardson
multiple copies Gtk+ also helped - I had linked in gtkmarshalers.o to get around the the above problem.  Consider my hand smacked for reaching into the cookie jar.   Thank you again. Mark  Owen Taylor <[EMAIL PROTECTED]> wrote: On Tue, 2006-09-26 at 19:08 -0700, Mark Richardson wrote:&

custom widget

2006-09-26 Thread Mark Richardson
ied taking the gtklabel widget and renaming it and all the functions to gtklabel2 - so as to simulate a correctly written widget for 2.10.  I get so many errors with this, so I must not be doing something right.   Thanks, Mark PS - I try not to bother ya'all, but I've been working

Re: Mandatory Access Control was Re: Plans for gnome-vfs replacement

2006-09-20 Thread Mark Seaborn
is no boundary between the application and the file chooser, or the application can otherwise supply the filename that is interpreted in the user's namespace, the application can grant itself access to files without the user having to choose them. Mark

ANNOUNCE: Plash 1.16, with Powerbox for Gtk

2006-03-18 Thread Mark Seaborn
ch replaces gtk_file_chooser_* functions. Would there be any interest in merging this functionality into mainline Gtk, so that the powerbox code can optionally be compiled in, and optionally be enabled at run time? Mark ___ gtk-devel-list mailing lis

Announce: Powerbox for Gtk, part of Plash 1.15

2005-12-17 Thread Mark Seaborn
-powerbox --pet-name "Leafpad" Mark ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: linking / performance / interposing detection ...

2005-12-14 Thread Mark McLoughlin
;static" somewhere? That seems to be the case for > parent_class in metal_gtk2_engine.c. I vaguely recall fixing that in some other theme engine at one point - it was causing crashes when you changed from that theme to another theme and back again

Re: Call-return interface for file choosers? (and: security using powerboxes)

2005-11-30 Thread Mark Seaborn
bug (quite possible considering it's written in > > C), and the spreadsheet exploits that bug. > > IMHO Evolution is a better example; it's constantly working with data > from the network, and you rarely need to deal with arbitrary > user-readable files (creating attachments i

Re: Call-return interface for file choosers? (and: security using powerboxes)

2005-11-28 Thread Mark Seaborn
Mike Hearn <[EMAIL PROTECTED]> wrote: > Hi Mark, > > I've looked briefly at this before. A few thoughts: > > * Rather than messing around with LD_PRELOAD and X proxies you really >just want to build your own patched copy of GTK+. This sort of change >

  1   2   >