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
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
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://
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://
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
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
__
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
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
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
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
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
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
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/
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
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
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
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
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
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
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
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
>> 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
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
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
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
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
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
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
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
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:/
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
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:
>> >
>> > >
>>
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
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
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
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
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
&
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
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
, 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
. 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
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
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
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
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
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.
>
>
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
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
___
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
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
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
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
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 <
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
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
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
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
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
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]>
_
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
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
;
...
}
g_matcher_free(record_matcher);
}
g_regexp_free(section_regexp);
The above would match again:
Hyperlinks:
hlink-selector "..." -> "..." hlink-selector
...
Notice all the st
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]
__
. .
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
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
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
>
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
-
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
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.
>
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
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
e derived gtype
Thanks,
Mark.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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
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
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
|\/| |_| |_
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
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
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:&
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
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
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
-powerbox --pet-name "Leafpad"
Mark
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
;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
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
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 - 100 of 111 matches
Mail list logo