On 1/19/06, Matthias Clasen [EMAIL PROTECTED] wrote:
On 8/27/05, Chipzz [EMAIL PROTECTED] wrote:
I'm not a Gtk+ developer, but I think one of the criteria for being
considered is: doesn't introduce a new library dependency, or maybe it
can, if it really makes sense. Gtk+ depending on a
On the Windows platform (as an example), there are standards for
richtext interchange between applications. Those standards are RTF and
to a lesser (but growing) extent, (X)HTML. You'll find that a lot of
the more richtext copy+paste centric apps on Linux and MacOS also
commonly use these
Hi Matthias,
*) The TextView can serialize and deserialize (a selection of) itself
into UTF-8 text, for the common copy + paste semantic.
Sure, it does that already.
Yup, I'm fully aware.
*) Applications are responsible for serializing and deserializing the
text view into more complex
Hi Tor,
BTW, the pthreads-win32 POSIX thread implementation from
http://sourceware.org/pthreads-win32/ just uses native thread-local
storage slots as allocated by TlsAlloc() in its implementation of
pthread_key_create(). The number of those is 1088 per process in
Windows 2000 and newer, and
I'm sorry for what may be a stupid question. Why do we need a bridge
API (assuming that there's a 1:1 mapping between Cocoa and GTK+ menus)
if we're already putting the onus on developers to:
1) Modify their menus to conform to MacOS style guidelines, including
putting entries into special menus
You might want to check out the GOffice graphing library. Gnumeric and
GnuCash both use it. cvs co goffice from Gnome's CVS.
Best,
Dom
On 4/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi!!
I've a problem to solve...
I need to graph some points in a graphic using GTK+.
And after graph
I haven't personally reviewed the patches yet but you mention changing
the color and look of a few widgets. Will these changes still work if
the theme is switched from the normal luna theme to one of the other
luna themes in windows XP? Do they pull in the appropriate values from
the Microsoft
This was my original thought but Matthias and others suggested this.
One of the issues with cairo is that we would have to either run through
the drawing commands on every expose event or save out to a bitmaps
surface which would remove the ability to zoom. The other option is to
recreate evince
Hi Carlos,
In evince we have the document pages already rendered, so can I take the
pixbuf of the page and create a cairo surface from it and use it in
draw_page signal? I don't know if this is the right way to do it.
Unless rendered at a high resolution, the output will probably look
pretty
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
Please read the documentation.
GdkEvent* gdk_display_peek_event (GdkDisplay *display);
http://developer.gnome.org/doc/API/2.0/gdk/GdkDisplay.html#gdk-display-peek-event
On 9/14/06, news.gmane.org [EMAIL PROTECTED] wrote:
Is there gdk function, which checks (only peeks) for certain
Hi Marco,
Please take my review with a grain of salt. I've been wanting a
convenience API on top of PCRE for a while now, and it would be great
if we could get something like GRegex into Glib proper.
1) Please don't name variables 'string', as there may be a conflict
with C++'s std::string
2) I
On 10/24/06, Behdad Esfahbod [EMAIL PROTECTED] wrote:
On Tue, 2006-10-24 at 16:05 -0400, Marco Barisione wrote:
If you prefer you can pass --enable-system-pcre to use the
system-supplied library but, if it's compiled without utf-8 support,
g_regex_new fails.
This is broken. It should
I think that the situation is much better than people here are making
it out to be. Or, at least that's been my experience.
I have Gaim, Gimp, Gnumeric, Glade-3, Workrave, gQview, and Xchat all
using the same GTK+ runtime on WinXP, and they all work flawlessly. As
far as I know, nothing gets
Maybe you got lucky, and didn't install anything that dumps shared DLLs to
System32. And you know how to get those applications to behave next to
eachother. Typical end-user doesn't.
The funny thing is that both you and Tor assumed that I did something
special that a normal end-user couldn't
Hi Lyonel,
What do I have to make GTK+ applications recognise icns files?
WMF and SVG support seem to suggest developing a GDK-Pixbuf loader.
I co-authored both of those loaders, so hopefully I can help you.
I've tried to create a shared lib modeled after io-wmf.so (in libwmf)
but without
I committed a similar patch yesterday. It was bug #403470.
Dom
On 4/20/07, Arnaud Charlet [EMAIL PROTECTED] wrote:
Sorry, I overlooked this message until now and just found your latest
patch. I will review this patch really soon, and if it looks okay I'll
get it committed to svn. Thanks
So does Gtk want to reduce themeing and just have a simple file that specifies
colors (like Metacity) or does it want to increase its features to allow stuff
such as allowing theme engines to do animations, fades and what do I know?
If we care about looking native on Win32 and OSX, I'd say
Hi Alex,
On 9/14/07, Alexander Larsson [EMAIL PROTECTED] wrote:
On Thu, 2007-09-13 at 14:12 -0400, Havoc Pennington wrote:
Hi,
There's a lot of code to absorb here, a minor comment, I might expect
GUnixFileInputStream/GWindowsFileInputStream rather than
GLocalFileInputStream.
Well,
The issue is that file descriptors shouldn't be passed from a dll / exe
using one C runtime to another using a different C runtime -- or if they
are, they must be used only with functions from the appropriate C
runtime. Use of file descriptors within a single dll is generally not a
problem.
Hi,
Is it possible to write a file plugin like
gdk-pixbuf/io-jpeg.c in c++?
Yes.
The problem is openexr expects a char* for
it's constructor and gdk works with FILE.
That doesn't have anything to do with C++ AFAICT.
The GdkPixbufLoader also has a push API, where a stream of bytes is
sent
The GdkPixbuf simple animation class implementation [1] uses an
internal iterator type. Unfortunately, the GObject type instantiation
function accidentally was placed in the header file instead of being a
static function in the source file.
Johan noticed a crash in the new defaultvaluetest when
Hi,
Arc and I are writing a GdkPixbuf plugin that wraps Window's GDI+
library. This library supports loading and saving a variety of
formats, such as PNG, JPEG, GIF, WMF, EMF, TIFF, ...
I'd like to implement saving to PNG/JPEG/whatever from the plugin.
GdkPixbuf's architecture allows you to
On Sat, Mar 15, 2008 at 4:18 AM, Tor Lillqvist [EMAIL PROTECTED] wrote:
Relatedly, I believe we should also consider bundling the 'native'
pixbuf loaders that have seen the light of day recently.
Sure. Will do soonish for the Win32 GDI+ one.
I've just committed proper support for
Hi Tor,
On Sun, Mar 16, 2008 at 4:27 AM, Tor Lillqvist [EMAIL PROTECTED] wrote:
I think that they're ready to go. Outside of the GTK+ tree, they won't
get much testing.
Do you think they cam unconditionally replace the traditional
loaders that depend on external libraries for Win32,
Hi Tor,
In order for that to happen, someone would need to re-design (at
minimum) GdkPixbuf's module and loader interfaces and use Windows
Vista or newer. Some notable problems are:
* The loader's create by type function uses the module's name (i.e.
gdi+ or png), rather than a mime-type. Lots of
* There is no way that I know of to distinguish between a
metafile/vector format and a raster format, except maybe to try
loading everything as a metafile and see if something fails.
Hmm, there are the ImageCodecFlagsSupportBitmap and
ImageCodecFlagsSupportVector bits in the
Hi Tor,
On Mon, Mar 17, 2008 at 10:26 PM, Tor Lillqvist [EMAIL PROTECTED] wrote:
Tentative patch at http://tml.pp.fi/gdip-in-gtk.diff . Comments, please.
A few things in io-gdip-utils.h need attention:
1) I redefined _() if it wasn't already defined. Instead, you probably
want to remove that
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 case. There is certainly no reference to the Windows
API in
This is open to interpretation - but the exact wording of the license does
not necessarily match the legal rights a person has in terms of copyright
law, and the ability for a copyright to limit the use of the product. In my
opinion, the special exception is not part of the license, but
It'd probably be easier to just install Xvfb: http://en.wikipedia.org/wiki/Xvfb
2008/5/16 Joshua Chia [EMAIL PROTECTED]:
I'm trying to use the GTK port of WebKit to render web pages to image
files. This normally would involve a simple hack, but I'm running this on a
Linux system that has no
A possible (though non-optimal) solution is to create 2 loaders - 1
for image/x-foo and 1 for image/x-bar. You can share 99% of the code,
and then pass the mime type to your decoder function, based on which
DLL got invoked. This is what the GDI+ based loaders do on Windows,
for instance.
Best,
What is wrong with:
gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n);
That's one not needed as strncpy should work.
hehe i know but that function it really exist:
http://library.gnome.org/devel/glib/unstable/glib-Unicode-Manipulation.html#g-utf8-strncpy
It does make sense.
Glib/gtk is full of macros. I believe que a C compiler is the right place to
this kind of unsafe code. If i want create safe code i have c#,c++, JAVA, D
or VALA.
Using macros is the only way to ensure intermediate APIs don´t have any
overhead. Besides modern GUIs have support to understand
That's hard-ish to do today. GTK+'s documentation is generated in
large part by scanning comments in C code, which a program then turns
into HTML. Any proposal would require a way to keep the Wiki and the C
comments in-sync.
On Thu, Feb 19, 2009 at 10:28 AM, Eugene Gorodinsky
Dominic Lachowicz domlachow...@gmail.com:
That's hard-ish to do today. GTK+'s documentation is generated in
large part by scanning comments in C code, which a program then turns
into HTML. Any proposal would require a way to keep the Wiki and the C
comments in-sync.
On Thu, Feb 19, 2009 at 10
Also, you could write a GdkPixbufLoader plugin, so that all GTK+ apps
can view MNGs. It shouldn't be too difficult.
On Tue, Mar 10, 2009 at 11:52 AM, Sven Neumann s...@gimp.org wrote:
Hi,
On Sat, 2009-03-07 at 10:37 +0530, Monil Parmar wrote:
I am using GTK-2.12.12.
I have compiled mng lib
Unfortunately this won't work for me. gdk_cairo_create() creates a Cairo
surface, then it creates a Cairo context from this surface, and then it
destroys the Cairo surface. What I am looking for is a function that creates
a Cairo surface and returns it directly. Then I can use pycairo to
Glib on Win32 has routines to solve this problem. It resolves things
relative to where the Glib DLL is installed. If your applications use
the XDG data directory functions in Glib, you might get away with this
too. Maybe you could invent something similar that used the OSX bundle
as your point of
implementing these APIs in terms of how the
operating system's packaging conventions behave.
Best,
Dom
On Sun, Jul 12, 2009 at 10:47 PM, John Rallsjra...@ceridwen.us wrote:
On Jul 12, 2009, at 6:18 PM, Dominic Lachowicz wrote:
Glib on Win32 has routines to solve this problem. It resolves things
If you want this sort of behavior, use a language like C++ that
supports stack-allocated objects natively. GtkMM and GlibMM already do
this wonderfully. Using a GNU-C ism which probably won't work with
most other C compilers (MSVC, LLVM, ICC, ...) feels wrong to me.
On Mon, Nov 21, 2011 at 10:34
Please excuse my ignorance, but why would the *users* need to download
and build anything? Why wouldn't GTK+ applications (eg. Pidgin) just
ship with the accessibility bridge included with their installer?
Thanks,
Dom
On Wed, Apr 18, 2012 at 11:24 AM, Евгений Филиппов
egphilip...@gmail.com
What is wrong with:
gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n);
That's one not needed as strncpy should work.
hehe i know but that function it really exist:
http://library.gnome.org/devel/glib/unstable/glib-Unicode-Manipulation.html#g-utf8-strncpy
It does make sense.
Glib/gtk is full of macros. I believe que a C compiler is the right place to
this kind of unsafe code. If i want create safe code i have c#,c++, JAVA, D
or VALA.
Using macros is the only way to ensure intermediate APIs don´t have any
overhead. Besides modern GUIs have support to understand
44 matches
Mail list logo
