Hello, there.
I'm currently working on an implementation of XEmbed, and have run
into a problem with XSetInputFocus. Please redirect me to the right
forum if this was posted to the wrong place.
What I'm troubled with is Keyboard Focus, described here:
Hello,
Both smproxy and gnome-smproxy has a bug. I will describe this
bug and propose solutions.
First I recall one paragraph of the X session manager protocol
(XSMP) specification:
Some clients may wish to manage the programs they start.
For example, a mail program could start a
Hi Dwipal,
Le jeu 31/07/2003 00:07, Dwipal Desai a crit :
that are very low. I want to use X directly over firewire so that stream
of around 300 MB/s can be obtained.
If I wanted to do this, I'd hack a firewire transport layer for X in
xc/lib/Xtrans/
Mathieu
--
Mathieu Lacage [EMAIL
hi,
I eventually got over my previous AddInputHandler puzzling and kept on
reading code until I finished the included rough outline of useful
code paths in the XServer.
I am planning to turn this into a real documentation but real life
matters make it unreasonable for me to finish this before
On Thu, 2003-07-31 at 09:29, Andreas Aardal Hanssen wrote:
Hello, there.
I'm currently working on an implementation of XEmbed, and have run
into a problem with XSetInputFocus. Please redirect me to the right
forum if this was posted to the wrong place.
What I'm troubled with is Keyboard
On Thu, Jul 31, 2003 at 07:15:43AM +0200, Alexander Pohoyda wrote:
David Dawes [EMAIL PROTECTED] writes:
going back to 3.3. Unless someone comes up with a better solution,
that's what I'm planning to do.
OK, it seems to be the best solution in this situation.
I dare to propose another
On Thu, Jul 31, 2003 at 03:25:23PM +0200, Olivier Chapuis wrote:
1. Remove smproxy from XFree and gnome-smproxy from GNOME with
the hope that all alive applications which use the old sm protocol
will switch to the new one. Probably a bad solution ...? By the
way it seems that KDE does not
Knowing all the problems now, I would still prefer this solution.
I have already developed 4 geometry specifications and will continue
to do so. I don't want to create problems, though :-)
OK, so if I understand you correctly, we can re-add the old 'hp' file,
and add the omnibook
On Thu, 31 Jul 2003, Owen Taylor wrote:
On Thu, 2003-07-31 at 09:29, Andreas Aardal Hanssen wrote:
- To emphasize, B isn't a child window of A (in XEmbed, the
embedder). B is a window created by a seperate application, which
has called XReparentWindow to reparent B into A. So B is the XEmbed
David Dawes [EMAIL PROTECTED] writes:
On Thu, Jul 31, 2003 at 07:15:43AM +0200, Alexander Pohoyda wrote:
I believe that this is a correct way to develop geometries for
related keyboards and I think that it is logical to combine them into
one file.
OK, so if I understand you correctly, we
In CVS I have just checked in something I've been working on
for a few weeks. It is a substantial rewrite of the nv driver,
the main changes being removal of Riva128 into a separate module
and a complete rewrite of the graphics acceleration for TNT and
GeForce chips. Aspects of the
11 matches
Mail list logo
