Hi,
A few dbus integration questions from an application developer who is
somewhat familiar with gtk internals and the win32 port.
* Would gtk be usable on posix-like platforms that do not have dbus
installed and configured? Does OS X fall into this category?
* What happens when something is
Torsten Schoenfeld wrote:
if (!g_thread_supported ())
g_thread_init (NULL);
bz! g_thread_supported called too early.
g_thread_supported is actually a macro. It's another name for
g_threads_got_initialized basically. So the idiom above should be safe,
right?
Just $.02,
Tor Lillqvist wrote:
- Can the support for 256-colour (palettized) display mode be dropped
from GTK+ HEAD?
I'm not doing this, not yet at least. If I can figure out a way to
test whether 256-colour mode works currently, and it doesn't, I will
drop it though...
256 color compatibility
Alexander Larsson wrote:
This does complicate the API a bit though. For instance, I'm not sure
how easy that would be to do with the win32 native dialogs.
I don't think there's anything in principle that makes this difficult on
Windows.
A couple of thoughts:
* It is a win for the user who
John (J5) Palmieri wrote:
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
Xavier Bestel wrote:
It does not cause any problem. Just some people want to switch from a
well-defined behavior (one PRIMARY per DISPLAY) to a fuzzy one: you want
to have several selections, but how many ?
- One selection per application ?
- One selection per window ?
- One selection per widget
Dominic Lachowicz wrote:
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:
Because hopefully gtk will make it possible to build a OS X application
Michael L Torrie wrote:
Yup this indeed a stickler. Given the current hodge-podge of menu
creating routines, plus the fact that menus are abstract in GTK (pop-up
menus, menubars, etc) doing this in an automated way seems to be very
difficult. I would be in favor of adding an API that could
Emmanuele Bassi wrote:
1. Make GTK+ depend on GConf
PROS: Makes this (and a lot of other similar problems) very easy
CONS: Doesn't work with OSX/Windows; likely to be very controversial
AFAIK, GConf pretty much works on win32; but it's the dependencies that
it brings along that are very
Owen Taylor wrote:
I think it should be possible to do basically the same thing in Python
by creating the GObject out of GObject.__new__() rather than out of
GObject.__init__().
This would break backwards compatibility.
__new__() calls g_object_new() calls ... -init() which allocates
the
Tor Lillqvist wrote:
Owen Taylor writes:
There is a third possible issue - if you are moving another window over
a window, does windows send:
ERASEBKGND
ERASEBKGND
ERASEBKGND
PAINT
Or is ERASEBKGN only sent immediately before PAINT?
If I understand correctly,
Tor Lillqvist wrote:
It was suggested to me on IRC that it is unnecessary (thanks!), and it
indeed seems so.
There's a patch for this at
http://bugzilla.gnome.org/show_bug.cgi?id=144269 It's definitely needed
to eliminate flickering when widgets are interactively resized. There
were issues
12 matches
Mail list logo
