GEM-dev December 2004

gem-dev@lists.iem.at

10 participants
13 discussions

Re: [PD-dev] pdp2gem question
by Johannes M Zmoelnig 13 Dec '04

13 Dec '04

james tittle wrote: > On Dec 9, 2004, at 6:33 PM, Yves Degoyon wrote: > >>> >> congatulations, amigo. > > > ...just glad to be able to move forward with what we talked about in > bergen! > hi all. sorry for cross-posting.... just for me to get an idea: what have you talked about in bergen ? just a summary about the gem/pdp-bridge (most is just guessing) [gem2pdp] and [pdp2gem] are there for quite some time (thanks yves) [gem2pdp] is slow (as it needs to grab the render-buffer) [gem2pdp] is somewhat clumsy as you need a gem-window even though you want to produce something in a pdp-window. (this is a problem of Gem) the "other" idea (tom's) was, to be able to build include pdp-chains within gem-chains; this is: one library would be master, the other one would be slave, as opposed to the egaliterian "bridge"-solution. it might be easier to code if Gem was master (as a first step). now how to avoid doubling of efforts ? mfg.a.sdr IOhannes

2 2

Re: [GEM-cvs] Gem/src/openGL setup.h,1.3,NONE
by james tittle 06 Dec '04

06 Dec '04

On Dec 6, 2004, at 4:02 AM, IOhannes m zmölnig wrote: > > Log Message: > now it's gone in this galaxis; where will it re-appear like undead ? IOhannes, ...did you spend the weekend watching sci-fi zombie movies again? :-) jamie

1 0

Re: [GEM-dev] Re: multiple_window: the questions begin!
by Johannes M Zmoelnig 02 Dec '04

02 Dec '04

Hans-Christoph Steiner wrote: > coming from Gem too. Maybe the way to do it would be to have a > [gemhid] object that outputs the same format as [hid]. (i do not know how to write "have you read all of the postings in this thread?" without appearing to be offensive. i don't know whether you are on gem-dev; so i ask the question without offense) i really think that the information provided by gem is per-window. as i understand hid it is rather "global", in a sense that you do not know where the information comes from. (well, it comes from "the mouse" of course) now the problem here is that we want multiple windows with distinct grabbing of hid-events (if we want "global" events, i think one should use [hid]). [gemmouse] (and friends) does not support this, as there is no way to specify the window it should listen too. so most naturally (for me) it seems to take pdp's (and others') approach to add an outlet to the [gemwindow] object that gives you this kind of "feedback" from this window. the output of this outlet should be standardized, and most probably the "HID format" would be the best choice (as ben suggested), as it seems to be easily extendible to new features of new hi-devices (e.g. scroll-wheels,...) > What I haven't understood about the Gem HID objects (gemmouse, > gemtablet, etc) is why they need to be distinct objects from the > standard Pd HID objects. sorry i do not understand this. if you complain about Gem's HID objects being unnecessary, you should have written your [hid] some years earlier (before april 1998; i am not sure whether HID was such a buzzword back then)... why we have several objects [gemmouse], [gemtablet], [gemkeyboard] i cannot really tell you. but it seemed a bad idea to output keyboard-information to [gemmouse]... > The only reason I can see is to have absolute > coordinates that match up the the gemwin. these coordinates are relative to the position of the gem-window (not absolute with respect to the desktop-origin). mfg.asd.r IOhannes

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev December 2004