On Tue, 18 Apr 2000, Stefan Seefeld wrote:
Well, from a practical point of view, how would I manage multiple input
queues ? Given a list of visuals (as you seem to suggest) acting as window,
I'd be forced into one thread per visual if I want to listen for events.
I had such a problem with
On 19 Apr 2000, Marcus Sundberg wrote:
teunis [EMAIL PROTECTED] writes:
[clip]
Okay. Can someone -please- fold the event sources in fb/... out into GII?
Seriously!
or something?
Huh? The input sources for the fbdev target are in LibGII.
No - they're initialized in fb's target.
Stefan Seefeld writes:
Ok, let's assume that windows listen themselfs for events. Then there
are cases where you want to draw into some 'output only' medium, a
Pixmap in X. Since Pixmaps and Windows in X are the same for the purpose
of output (drawing), they are generalized to
On 2000/Apr/19, Andrew Apted wrote:
Like SDL's "surfaces" ? I.e. non-visible places to draw stuff, maybe
blitting them to the visible screen/window at some stage, right ?
LibGGI has nothing like that yet (I hope it will someday). The
closest it comes is either using a large virtual area
Huh? The input sources for the fbdev target are in LibGII.
No - they're initialized in fb's target.
Initialized yes ... but you can as well simply use LibGII only if you want
to get events without disturbing output.
It's pretty much a matter of opening the stuff LibGGI would open for you
Andrew Apted wrote:
Personally, the idea of getting input "independently" of the output
doesn't feel right. The traditional "window" is a good abstraction,
it is a place to draw stuff for the user, and a place to receive the
feedback from the user.
But you don't listen to a window for
I have argued in the past for a more formal separation of LibGII
from LibGGI. This would decouple the event queues from ggi_visual(s).
Actually they are separated. LibGII provides all event functionality.
All that LibGGI does is automatically locate and load the approriate
"default"
Andreas Beck wrote:
On a different note: the Berlin project will present itself
on LinuxTag in Stuttgart this year, both, with a booth as
well as in a talk. Does anyone from GGI intend to show up
in Stuttgart ? May be we could meet and discuss various
aspects of the above...
When
According to me email software Stefan Seefeld wrote:
| Andrew Apted wrote:
| Personally, the idea of getting input "independently" of the output
| doesn't feel right. The traditional "window" is a good abstraction,
| it is a place to draw stuff for the user, and a place to receive the
|
[EMAIL PROTECTED] wrote:
| But you don't listen to a window for events. You listen to the server
| connection ('XDisplay') for events which *refer* to windows. A window -
| as it is seen by the application - is completely unaware of events.
The ability to listen to the display as a whole
Once upon a time I wrote:
| But you don't listen to a window for events. You listen to the server
| connection ('XDisplay') for events which *refer* to windows. A window -
| as it is seen by the application - is completely unaware of events.
The ability to listen to the display as a whole
On Mon, Apr 17, 2000 at 11:39:35AM -0400, Stefan Seefeld wrote:
On a different note: the Berlin project will present itself
on LinuxTag in Stuttgart this year, both, with a booth as
well as in a talk. Does anyone from GGI intend to show up
in Stuttgart ? May be we could meet and discuss
teunis [EMAIL PROTECTED] writes:
On Tue, 18 Apr 2000, Andreas Beck wrote:
I have argued in the past for a more formal separation of LibGII
from LibGGI. This would decouple the event queues from ggi_visual(s).
Actually they are separated. LibGII provides all event functionality.
The LinuxTag is from 29.06 to 02.07. in Stuttgart.
Looks good. It's on a WE, so it might be well possible.
CU, ANdy
--
= Andreas Beck| Email : [EMAIL PROTECTED] =
smpeg runs on top of SDL, which runs on top of GGI, shouldn't be
very difficult to make a wrapper that makes user think that is running
directly on top of GGI.
That's not quite the point. I think one should try to separate the
displaying part from the decompression part. I would e.g.
On Sun, 16 Apr 2000, Andreas Beck wrote:
I've downloaded libsmpeg, and after seeing the API, I have seen two
things that I dislike:
* it needs SDL
* it is in C++
Is somebody porting the code of this library to a pure C version
based only on GGI maybe into an extension or
Speaking about video and animation, may I come back to
a suggestion I had a couple of weeks back ?
I proposed to separate the 'Visual' structure into a
'Drawable' and a part concerned about event handling.
The argument is quite in line with Andreas' request to
refactor functionality in
On Mon, 17 Apr 2000, Stefan Seefeld wrote:
Speaking about video and animation, may I come back to
a suggestion I had a couple of weeks back ?
I proposed to separate the 'Visual' structure into a
'Drawable' and a part concerned about event handling.
The argument is quite in line with
teunis wrote:
The original reason I suspect for the event handling and drawing to be
merged was X, where this is necessary.
No. Even in X you can allocate an 'XPixmap' which is a 'XDrawable' without
any attached event queue. In X you need one 'XDisplay' representing the
connection and all
Andreas Beck [EMAIL PROTECTED] writes:
But there is a problem with C++, how can you make an extension that uses
C++ ?
I have no idea.
AFAIK if you try to resolve a function name compiled with C++ from libdl,
it doesn't run...
Maybe one has to manually demangle the function
On Mon, 17 Apr 2000, Stefan Seefeld wrote:
teunis wrote:
The original reason I suspect for the event handling and drawing to be
merged was X, where this is necessary.
No. Even in X you can allocate an 'XPixmap' which is a 'XDrawable' without
any attached event queue. In X you need
Andreas Beck wrote:
Maybe could be done with 'extern "C" {' ?
Probably, if the callable functions don't use C++-Features, that should
work.
*In* these functions you can use C++ features to you heart's content, as
long as the function's signature looks C-ish (i.e. you don't pass objects
etc).
Stefan Seefeld [EMAIL PROTECTED] writes:
Speaking about video and animation, may I come back to
a suggestion I had a couple of weeks back ?
I proposed to separate the 'Visual' structure into a
'Drawable' and a part concerned about event handling.
The argument is quite in line with
On 18 Apr 2000, Marcus Sundberg wrote:
Stefan Seefeld [EMAIL PROTECTED] writes:
Speaking about video and animation, may I come back to
a suggestion I had a couple of weeks back ?
I proposed to separate the 'Visual' structure into a
'Drawable' and a part concerned about event
On Mon, 17 Apr 2000, Stefan Seefeld wrote:
Speaking about video and animation, may I come back to
a suggestion I had a couple of weeks back ?
I proposed to separate the 'Visual' structure into a
'Drawable' and a part concerned about event handling.
In LibXMI, there is the concept
I've downloaded libsmpeg, and after seeing the API, I have seen two
things that I dislike:
* it needs SDL
* it is in C++
Is somebody porting the code of this library to a pure C version
based only on GGI maybe into an extension or something?
--
__
)_) \/ / /
I've downloaded libsmpeg, and after seeing the API, I have seen two
things that I dislike:
* it needs SDL
* it is in C++
Is somebody porting the code of this library to a pure C version
based only on GGI maybe into an extension or something?
I think there are many people
27 matches
Mail list logo
