nuiDragAndDrop.cpp:35: warning: deleting `void*' is undefined
nuiDragAndDrop.cpp:44: warning: deleting `void*' is undefined
Obviously, err...
nuiDragAndDrop.cpp:95: no match for `nuiDragData& = nuiDragData' operator
It searches for a operator=(const ...). But we can't const the actual
operator= since it does a mOwnData=false on the right operand, unless we turn
'mOwnData' as mutable. It clearly shows that this operator= is a _very_ bad
idea, at least wrt to the data ownership transfer which is far from obvious. A
reference counter would be more appropriate, or better, no operator=.
I personnally don't see the point in nuiDragData. We're doing OO, objects
(pointers) should be attached to types (sadly downcasted to void*), not byte
buffers. Objects manage their own life cycle, that's the whole point.
IMHO the current implementation is not exactly what I would expect. I don't see
the point in nuiMainWindow being a mediator and again being stuffed with more
code. nuiWidget should hold the code to detect the dnd start condition, then
create a 'draggable widget' (which can also holds code to display the thingy
being dragged, a nuiImage would do I guess), give it the grab. Then on ungrab
we simply fire a dnd event to the destination with the 'draggable widget' and
let it use it and destroy it when done. Even if it needs some glue in
nuiMainWindow, it should be somethink like 5 lines max.
BTW, there's already some 'drag' code for nuiWindow's, that should rely on the
same code for dnd start detection (?) That's why I expect it in nuiWidget.
--
I'm getting worried for the nuiTopLevel/nuiMainWindow separation job, even more
if it keeps growing with code that manages a zillion features of NUI. So I'll
try to first migrate those 'features' to their respective objects, in order
that they all remain available before extracting nuiTopLevel.
nuiDragAndDrop just crept in, I hope it'll reduce to something like a pointer
and 2 or 3 lines for event routing.
nuiToolTip should be its own widget, it only needs a global to provide the
uniqueness of a tooltip on display. Hey, I'll want to have HTML-text or more
sexy tootltips in the future, so I'll make it a regular container. Of course
nuiToolTipLabel will be a first class tooltip.
Same things for the graphical debug trace, it should move to nuiWidget.
In conclusion, the toplevel widget should only contain those strict necessaries
'globals' and maybe event routing specifics. I see much 'object->' blocks here
and there that say "hey, move this code to <object> !". Ex:
if (pObject->OnCanDrag(mpDragObject,x,y))
{
mpDragObject->SetDestination(pObject);
mpDragObject->GetSource()->OnDragged(mpDragObject);
mpDragObject->GetDestination()->OnDropped(mpDragObject,x,y,Button);
}
else
{
mpDragObject->SetDestination(NULL);
mpDragObject->GetSource()->OnCancelDrag(mpDragObject);
}
Doesn't ring a bell ??
--
That's actually only when nuiMainWindow will be restricted to its strict
functionalities that I will separate nuiTopLevel. Hence in the process we
should always have dnd, tooltips and debug operating happily since I'll migrate
them one by one.
I'm _heavily_ thinking of using NUI at work, in a huge projects where
maintenance should be my least conern or I'll never make it. I want to be able
to ask *a lot* from NUI, thus I need to see far away. That's why I'll be
pushing hard for 'orthogonality' in APIs and make sure we don't have classes
that 'make coffee and more'. See NGL application rewrite : the code is
considerably smaller and easier to read (I can testify for Unix and Win32 :)).
To think 'orthogonal', just ask yourself when you design a new class : "could I
easily exclude it from build without compromising the whole library ?". If your
class just can't "plug", it's maybe only because a little "socket" is missing
:).
Just imagine that 3 weeks ago NGL could not be compiled without nglImage and
codec selectively compiled in : that was only a matter of 15 misplaced lines of
code. Etc.
PS: the default GTK+ 1.x text widget sucks hard. I'm using it to write this
mail.
NUI rules by far.
Received: from ivsweb.net2.nerim.net ([62.212.112.100] helo=ivssbs.IVSDOMAIN.FR)
by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 1891ON-0008JE-00
for <[EMAIL PROTECTED]>; Tue, 05 Nov 2002 02:57:07 -0800
Received: from harry ([192.168.0.54]) by ivssbs.IVSDOMAIN.FR with Microsoft
SMTPSVC(5.0.2195.5329);
Tue, 5 Nov 2002 12:01:14 +0100
Message-ID: <[EMAIL PROTECTED]>
From: "Sebastien Metrot" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Subject: Re: [NGL-devel] nui: compile pb with nuiDragAndDrop.cpp (and more)
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 05 Nov 2002 11:01:14.0625 (UTC)
FILETIME=[A88AD710:01C284BA]
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Tue Nov 5 02:58:02 2002
X-Original-Date: Tue, 5 Nov 2002 11:38:22 +0100
----- Original Message -----
From: "Vincent Caron" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 05, 2002 1:45 AM
Subject: [NGL-devel] nui: compile pb with nuiDragAndDrop.cpp (and more)
> nuiDragAndDrop.cpp:35: warning: deleting `void*' is undefined
> nuiDragAndDrop.cpp:44: warning: deleting `void*' is undefined
>
> Obviously, err...
Erm... yeah, that's a problem for sure.
>
> nuiDragAndDrop.cpp:95: no match for `nuiDragData& = nuiDragData' operator
>
> It searches for a operator=(const ...). But we can't const the actual
operator= since it does a mOwnData=false on the right operand, unless we
turn 'mOwnData' as mutable. It clearly shows that this operator= is a _very_
bad idea, at least wrt to the data ownership transfer which is far from
obvious. A reference counter would be more appropriate, or better, no
operator=.
>
> I personnally don't see the point in nuiDragData. We're doing OO, objects
(pointers) should be attached to types (sadly downcasted to void*), not byte
buffers. Objects manage their own life cycle, that's the whole point.
>
I was thinking along the same line: the Drag operation will contain a list
of object derived from nuiObject with their mime type contained in a
property, that should solve the problem and permit much more complex
operations.
> IMHO the current implementation is not exactly what I would expect. I
don't see the point in nuiMainWindow being a mediator and again being
stuffed with more code. nuiWidget should hold the code to detect the dnd
start condition, then create a 'draggable widget' (which can also holds code
to display the thingy being dragged, a nuiImage would do I guess), give it
the grab. Then on ungrab we simply fire a dnd event to the destination with
the 'draggable widget' and let it use it and destroy it when done. Even if
it needs some glue in nuiMainWindow, it should be somethink like 5 lines
max.
>
I agree (after thinking about it a bit more). What I did first was just tran
slating the usual D'n'D API as seen elsewhere (Win32, Carbon, Mac Classic
mainly). The idea behind making nuiMainWindow a mediator is that I don't
want to restrain D'n'D to just work inside nui and I'd really like to add
the functionality to drag files from the finder/explorer to a nui
application or text from the nui app to another app in the future (i usually
use a mediator with my guitar but well :).
I hadn't thought about doing it this way but i agree it's a nice idea and it
makes for a clean design. Unfortunately you where not available for a talk
when I started this whole drag and drop thingy.
> BTW, there's already some 'drag' code for nuiWindow's, that should rely on
the same code for dnd start detection (?) That's why I expect it in
nuiWidget.
>
We'll have to separate this from the rest of the code to enable any widget
to detect a move operation (not just for DnD and nuiWindow). Do you have an
idea about the way the API for this should look like?
> --
>
> I'm getting worried for the nuiTopLevel/nuiMainWindow separation job, even
more if it keeps growing with code that manages a zillion features of NUI.
So I'll try to first migrate those 'features' to their respective objects,
in order that they all remain available before extracting nuiTopLevel.
>
> nuiDragAndDrop just crept in, I hope it'll reduce to something like a
pointer and 2 or 3 lines for event routing.
>
Don't worry about DnD, it is only a few lines long and it will not stay
there if the idea of using a drag widget really works.
> nuiToolTip should be its own widget, it only needs a global to provide the
uniqueness of a tooltip on display. Hey, I'll want to have HTML-text or more
sexy tootltips in the future, so I'll make it a regular container. Of course
nuiToolTipLabel will be a first class tooltip.
>
I'll think about it but to be frank it's NOT a priority for me right now.
You're welcome to do something about it but please don't break the current
API. Particularly I really want this feature to be easy to use and using a
property to hold the tooltip is really nice and permits to manage a widget's
tooltip in a totaly clean and great way. For the HTML thingy we can imagine
to put HTML (or an nui XML description) directly in the tooltip property.
> Same things for the graphical debug trace, it should move to nuiWidget.
>
Same thing here. As these widgets have special meanings you will need
special glue code in the main window anyway (or top level or what ever).
> In conclusion, the toplevel widget should only contain those strict
necessaries 'globals' and maybe event routing specifics. I see much
'object->' blocks here and there that say "hey, move this code to <object>
!". Ex:
>
> if (pObject->OnCanDrag(mpDragObject,x,y))
> {
> mpDragObject->SetDestination(pObject);
> mpDragObject->GetSource()->OnDragged(mpDragObject);
>
mpDragObject->GetDestination()->OnDropped(mpDragObject,x,y,Button);
> }
> else
> {
> mpDragObject->SetDestination(NULL);
> mpDragObject->GetSource()->OnCancelDrag(mpDragObject);
> }
>
> Doesn't ring a bell ??
>
I can see your point.
>
> I'm _heavily_ thinking of using NUI at work, in a huge projects where
maintenance should be my least conern or I'll never make it. I want to be
able to ask *a lot* from NUI, thus I need to see far away. That's why I'll
be pushing hard for 'orthogonality' in APIs and make sure we don't have
classes that 'make coffee and more'. See NGL application rewrite : the code
is considerably smaller and easier to read (I can testify for Unix and Win32
:)).
>
That would be great.
You seem to like "othogonal" a lot lately, did you found a book on "OO
design paterns buzz words"? ;-D.
>
> PS: the default GTK+ 1.x text widget sucks hard. I'm using it to write
this mail.
> NUI rules by far.
>
Here, I'm not sure the goal is to fight GTK/Qt/KDE/wxWin right now :-).
I'd like to hear Jerome's ideas about features and APIs here, he's the one
that made the most use of nui right now and I believe his experience should
help us point weaknesses and strength in nui design.
MeeLoo
Received: from zerodeux.net ([62.212.104.175])
by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 189dxF-0005cn-00
for <[EMAIL PROTECTED]>; Wed, 06 Nov 2002 20:07:41 -0800
Received: from zerodeux.home (zerodeux.home [192.168.1.3])
by zerodeux.net (Postfix) with SMTP id 479B0B2E3
for <[EMAIL PROTECTED]>; Thu, 7 Nov 2002 05:07:42 +0100 (CET)
From: Vincent Caron <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Message-Id: <[EMAIL PROTECTED]>
X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i386-debian-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: [NGL-devel] nglVisual and GL contexts
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Wed Nov 6 20:08:06 2002
X-Original-Date: Thu, 7 Nov 2002 05:07:28 +0100
Hello,
while I was working on nglContext implementation, it occured to me that it
could replace nglVisual efficiently. We're back to the GLX/WGL model, so I hope
you had a nice trip :)
nglContext has been planned for a long time and was expected to be the base
class of renderable surfaces, nglWindow and over pbuffer offscreens being
examples. It will also be the holder of pointers to the GL extension functions,
since they are context dependent.
nglContext is an 'abstract class' because it has a protected default
constructor. It does not build a GL context in the constructor, the superclass
call Build() when desired. The net effect is that we now properly support
multiple monitors, see these GLX and Win32 methods :
bool Build(HDC hDC, nglContextInfo& rInfo, const nglContext* pShared);
bool Build(int Screen, const nglContextInfo& rInfo, const nglContext*
pShared);
nglContextInfo is a simple holder like a PixelFormat descriptor, and use both
as input (user fills in value, constructor helps a lot) and as output (extract
info from a context). Thus we rely on the wgl/glx/agl PixelFormat selection
routine. One wheel I'm happy not to reinvent :). By means of Enum(), the user
can still implement its own selection algorithm, it's just a matter of picking
the right one.
The implementation and the port went pretty smoothly (from 0:30 to 5:00). I
have the nice feeling that it's simple, it works, and that this boring topic is
about to be finaly DONE :). I will do the win32 port in the next 24h at work.
The next feature will be the actual primary goal : GL extensions support. A
(perl) script extract protos from <GL/glext.h> and stuff them in nglContext. As
long as you call GL primitives in the nglContext or nglWindow scope (which is
more than a good idea :)), it's transparent. Ex:
if (ARB_vertex_program)
{
glVertexProgramBeginARB();
...
To be continued...
Received: from mallaury.noc.nerim.net ([62.4.17.82])
by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 189lHD-0003pN-00
for <[EMAIL PROTECTED]>; Thu, 07 Nov 2002 03:56:47 -0800
Received: from zerodeux.net (mksp.net2.nerim.net [62.4.19.30])
by mallaury.noc.nerim.net (Postfix) with ESMTP id A592962D69
for <[EMAIL PROTECTED]>; Thu, 7 Nov 2002 12:56:42 +0100 (CET)
Message-ID: <[EMAIL PROTECTED]>
From: Vincent Caron <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a)
Gecko/20020910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [NGL-devel] Re: [ngl-cvs] stupid looking modifs for gcc 2.95-4
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Thu Nov 7 03:57:05 2002
X-Original-Date: Thu, 07 Nov 2002 12:57:08 +0100
Sebastien Metrot wrote:
> *Commit from /meeloo/* 2002/11/07 03:06:13
>
> ------------------------------------------------------------------------
>
> | stupid looking modifs for gcc 2.95-4
IMHO it's a bad idea to have sometimes pointers, sometimes references,
so gcc is right to shout. My experienced show problems while using
polymorphism with references, and I only use pointers when I need
polymorphism (and dynamic allocation, of course :)). What does the
Stroustrup says ?
Received: from ivsweb.net2.nerim.net ([62.212.112.100] helo=ivssbs.IVSDOMAIN.FR)
by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 189lTx-0006Jy-00
for <[EMAIL PROTECTED]>; Thu, 07 Nov 2002 04:09:57 -0800
Received: from harry ([192.168.0.54]) by ivssbs.IVSDOMAIN.FR with Microsoft
SMTPSVC(5.0.2195.5329);
Thu, 7 Nov 2002 13:14:03 +0100
Message-ID: <[EMAIL PROTECTED]>
From: "Sebastien Metrot" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Subject: Re: [NGL-devel] Re: [ngl-cvs] stupid looking modifs for gcc 2.95-4
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 07 Nov 2002 12:14:03.0703 (UTC)
FILETIME=[298ABC70:01C28657]
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Thu Nov 7 04:10:06 2002
X-Original-Date: Thu, 7 Nov 2002 13:09:46 +0100
No, GCC is stupid to shout about this :
void Blurg(MyClass& Thing);
...
Blurg(MyClass(...));
I really don't see the point. Why should we const all these???
MeeLoo
----- Original Message -----
From: "Vincent Caron" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 07, 2002 12:57 PM
Subject: [NGL-devel] Re: [ngl-cvs] stupid looking modifs for gcc 2.95-4
> Sebastien Metrot wrote:
> > *Commit from /meeloo/* 2002/11/07 03:06:13
> >
> > ------------------------------------------------------------------------
> >
> > | stupid looking modifs for gcc 2.95-4
>
> IMHO it's a bad idea to have sometimes pointers, sometimes references,
> so gcc is right to shout. My experienced show problems while using
> polymorphism with references, and I only use pointers when I need
> polymorphism (and dynamic allocation, of course :)). What does the
> Stroustrup says ?
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> NGL-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/ngl-devel
>
Received: from mallaury.noc.nerim.net ([62.4.17.82])
by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 189qhL-0007Nz-00
for <[EMAIL PROTECTED]>; Thu, 07 Nov 2002 09:44:07 -0800
Received: from zerodeux.net (mksp.net2.nerim.net [62.4.19.30])
by mallaury.noc.nerim.net (Postfix) with ESMTP id 62A2162D38
for <[EMAIL PROTECTED]>; Thu, 7 Nov 2002 18:43:59 +0100 (CET)
Message-ID: <[EMAIL PROTECTED]>
From: Vincent Caron <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a)
Gecko/20020910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
Subject: Re: [NGL-devel] Re: [ngl-cvs] stupid looking modifs for gcc 2.95-4
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Thu Nov 7 09:45:02 2002
X-Original-Date: Thu, 07 Nov 2002 18:44:24 +0100
Sebastien Metrot wrote:
> No, GCC is stupid to shout about this :
> void Blurg(MyClass& Thing);
>
> ...
> Blurg(MyClass(...));
>
> I really don't see the point. Why should we const all these???
It's not a bug, it's a feature :). That's exactly what's stated there :
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?database=gcc&cmd=view%20audit-trail&pr=672
Now ask Stroustrup why this behaviour was chosen in the C++ standard, he
surely has a good reason but forgot to tell us. Or it's maybe written in
the standard, I don't have a copy at hand to check chapter 3.10.
Received: from zerodeux.net ([62.212.104.175])
by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 18BPcv-0004aY-00
for <[EMAIL PROTECTED]>; Mon, 11 Nov 2002 17:14:02 -0800
Received: from zerodeux.net (zerodeux.home [192.168.1.3])
by zerodeux.net (Postfix) with ESMTP id D346EAFC6
for <[EMAIL PROTECTED]>; Tue, 12 Nov 2002 02:14:01 +0100 (CET)
Message-ID: <[EMAIL PROTECTED]>
From: Vincent Caron <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913
Debian/1.1-1
X-Accept-Language: en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [NGL-devel] Fullscreen inconsistency in nglContext & nglVideoMode
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Mon Nov 11 17:15:02 2002
X-Original-Date: Tue, 12 Nov 2002 02:13:50 +0100
First, in nglContextInfo : the FullScreen boolean has never had a clear
definition nor implementation (even in defunct nglVisual). The meaning I
chose was : if false, this context is suitable for a regular window, if
true the context is suitable for a fullscreen window. That's why
nglContextInfo::Enum() currently return one system PFD/XVisual twice :
one with fullscreen set, one with fullscreen unset. Not very interesting.
I guess the correct information for the fullscreen flag would be "need a
video mode change", since it should be unlikely to be granted a 16bit
frame buffer on a 32bit desktop, and vice versa. Setting this flag would
be then dependent from the current video mode : if current bitdepth is
32, we'll tag all no-32bit frame buffers has fullscreen-required.
nglContextInfo::Enum() would return different results, depending on the
current video mode.
Questions are :
- does context and fullscreen dependencies are clearly stated above ?
- what should be the name of this flag ? (NeedVideoModeSwitch)
- do we really need this flag ?
We could hide this context/video mode dependency : the bitdepth is a
matter of nglContextInfo (frame buffer resolution) and resolution is a
matter of nglWindow (physical dimensions). So at nglWindow construction
time :
- if the context's framebuffer bitdepth is different from the current
desktop's one, we prepare for a video mode change (same dimensions,
different bitdepth)
- if the nglWindowInfo has a fullscreen flags, we prepare for a video
mode change using window dimensions
- given the two previous informations, we can do the right WxHxD video
mode change
In theory this should let the user play with different bitdepths while
still in window'ed mode, and hide context bitdepth/video mode switching
relationship from the user.
I prefer this last solution because it's higher-level and makes more
sense from a user point of view : changing video mode is a boring
detail, while selecting a context's frame buffer or chosing to go
fullscreen are legal user concerns. And there's actually almost no code
to change/modify, since nglWindow already gathers information from
nglContextInfo and nglWindowInfo before deciding to switch video mode.
Most of the work would be in the doc.
It would also enable me to cleanup a bit the nglContextInfo default
constructor and clearly states that the default framebuffer has the same
RGB layout as the desktop.
The main pb is that we don't really care/test these situations.
Everybody runs 32bit or die :). However we should get ready for floating
point frame buffers (Radeon 9700 & NV30) ...
--
The other problem comes with nglWindow : there's no way to provide a
nglVideoMode object at construction time. If the fullscreen flag is set,
we do a nglVideoMode::Find(), which does not necessarily find what we
want. I like going fullscreen without actually changing video mode, but
with the current scheme Find() returns the 60Hz mode first : I end up
with both an annoying CRT reprogrammation and a flickering display ! The
fix is not in Find(), I'm not using the best refresh rate either. Since
we can enumerate all video modes, we should be able to use any one of
them and select one ourselves. I propose :
- nglWindow(Width, Height, FullScreen, FallBack=true)
* uses nglVideoMode::Find(eVideoModeExact)
* should we fix Find() to return best frequencies first ? (yes)
* do we add a 'WindowFallback' to fallback on window'ed mode ? (yes)
- nglWindow(nglContextInfo&, nglWindowInfo&)
* we should add a nglVideoMode field to nglWindowInfo
* we should add a flag to let fullscreen fallback using window'ed
mode with the regular Width and Height fields (nglWindowInfo too)
The fallback mecanism is a good crap-proof feature IMHO, since a bunch
of warlordz-coded OpenGL apps around insist to go fullscreen and can
fail miserably to do so. Or I actually don't care going 320x200 to see
an incredible FPS. Etc.
PS: I'm not sure of this last feature, it's actually none of my concern
under X11 (frequency settings are not part of the presets).
Received: from ivsweb.net2.nerim.net ([62.212.112.100] helo=ivssbs.IVSDOMAIN.FR)
by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 18Bein-0000Rd-00
for <[EMAIL PROTECTED]>; Tue, 12 Nov 2002 09:21:07 -0800
Received: from harry ([192.168.0.54]) by ivssbs.IVSDOMAIN.FR with Microsoft
SMTPSVC(5.0.2195.5329);
Tue, 12 Nov 2002 18:25:18 +0100
Message-ID: <[EMAIL PROTECTED]>
From: "Sebastien Metrot" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Subject: Re: [NGL-devel] Fullscreen inconsistency in nglContext & nglVideoMode
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 12 Nov 2002 17:25:18.0437 (UTC)
FILETIME=[789DC150:01C28A70]
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Tue Nov 12 09:22:01 2002
X-Original-Date: Tue, 12 Nov 2002 18:20:59 +0100
----- Original Message -----
From: "Vincent Caron" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 12, 2002 2:13 AM
Subject: [NGL-devel] Fullscreen inconsistency in nglContext & nglVideoMode
> First, in nglContextInfo : the FullScreen boolean has never had a clear
> definition nor implementation (even in defunct nglVisual). The meaning I
> chose was : if false, this context is suitable for a regular window, if
> true the context is suitable for a fullscreen window. That's why
> nglContextInfo::Enum() currently return one system PFD/XVisual twice :
> one with fullscreen set, one with fullscreen unset. Not very interesting.
>
Sure
> I guess the correct information for the fullscreen flag would be "need a
> video mode change", since it should be unlikely to be granted a 16bit
> frame buffer on a 32bit desktop, and vice versa. Setting this flag would
> be then dependent from the current video mode : if current bitdepth is
> 32, we'll tag all no-32bit frame buffers has fullscreen-required.
> nglContextInfo::Enum() would return different results, depending on the
> current video mode.
>
Ok.
> Questions are :
> - does context and fullscreen dependencies are clearly stated above ?
Seems so
> - what should be the name of this flag ? (NeedVideoModeSwitch)
Can't find a better one at the moment.
> - do we really need this flag ?
I think it provides a nice information that is straitforward to understand
and use.
>
> We could hide this context/video mode dependency : the bitdepth is a
> matter of nglContextInfo (frame buffer resolution) and resolution is a
> matter of nglWindow (physical dimensions). So at nglWindow construction
> time :
>
> - if the context's framebuffer bitdepth is different from the current
> desktop's one, we prepare for a video mode change (same dimensions,
> different bitdepth)
> - if the nglWindowInfo has a fullscreen flags, we prepare for a video
> mode change using window dimensions
> - given the two previous informations, we can do the right WxHxD video
> mode change
>
This is touchy.
> In theory this should let the user play with different bitdepths while
> still in window'ed mode, and hide context bitdepth/video mode switching
> relationship from the user.
>
Hmm; I think the user have to know when his choices will produce a video
mode change. I just hate it when my screen changes resolution without
telling.
> I prefer this last solution because it's higher-level and makes more
> sense from a user point of view : changing video mode is a boring
> detail, while selecting a context's frame buffer or chosing to go
> fullscreen are legal user concerns. And there's actually almost no code
> to change/modify, since nglWindow already gathers information from
> nglContextInfo and nglWindowInfo before deciding to switch video mode.
> Most of the work would be in the doc.
>
> It would also enable me to cleanup a bit the nglContextInfo default
> constructor and clearly states that the default framebuffer has the same
> RGB layout as the desktop.
>
> The main pb is that we don't really care/test these situations.
> Everybody runs 32bit or die :). However we should get ready for floating
> point frame buffers (Radeon 9700 & NV30) ...
>
The windows version of the code did test the resolution of the desktop and
adapted the context request to it in order to be sure to get an hardare
accelerated context.
Most of the time it is a good practice to provide visual feeback to the user
about what will hapend with the settings he has chosen so giving the
opportunity to the programmer to easily fetch this info seems important to
me. Even so I agree with the global scheme.
> --
>
> The other problem comes with nglWindow : there's no way to provide a
> nglVideoMode object at construction time. If the fullscreen flag is set,
> we do a nglVideoMode::Find(), which does not necessarily find what we
> want. I like going fullscreen without actually changing video mode, but
> with the current scheme Find() returns the 60Hz mode first : I end up
> with both an annoying CRT reprogrammation and a flickering display ! The
> fix is not in Find(), I'm not using the best refresh rate either. Since
> we can enumerate all video modes, we should be able to use any one of
> them and select one ourselves. I propose :
>
> - nglWindow(Width, Height, FullScreen, FallBack=true)
> * uses nglVideoMode::Find(eVideoModeExact)
> * should we fix Find() to return best frequencies first ? (yes)
> * do we add a 'WindowFallback' to fallback on window'ed mode ? (yes)
>
> - nglWindow(nglContextInfo&, nglWindowInfo&)
> * we should add a nglVideoMode field to nglWindowInfo
> * we should add a flag to let fullscreen fallback using window'ed
> mode with the regular Width and Height fields (nglWindowInfo too)
>
> The fallback mecanism is a good crap-proof feature IMHO, since a bunch
> of warlordz-coded OpenGL apps around insist to go fullscreen and can
> fail miserably to do so. Or I actually don't care going 320x200 to see
> an incredible FPS. Etc.
>
> PS: I'm not sure of this last feature, it's actually none of my concern
> under X11 (frequency settings are not part of the presets).
>
This is quite dangerous!!! Getting the best frequency can fry you monitor
for multiple reasons. For exemple my old 17" screen is getting a bit too old
and now really dislikes some high frequencies that he used to accept without
problems some years ago, and unfortunately there is no way to ask windows
(or MacOS) to remove a particular frequency from the ones listed by a
particular monitor driver. There may be a way to get the users windows
preference for a particular resolution (i think that asking for a frequency
of 0 in the change mode function will retains user settings, and that's what
it does right now if i'm not mistaken).
I think many issues presented here really are dependent on the actual
application programmer (he have to provide a good configuration dialog for
his application/game like permit quick canceling of video screen change and
all [like detect the destruction of the esc key by the user ;-)] ).
MeeLoo
Received: from mallaury.noc.nerim.net ([62.4.17.82])
by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 18Eq0I-0001b7-00
for <[EMAIL PROTECTED]>; Thu, 21 Nov 2002 04:00:18 -0800
Received: from zerodeux.net (mksp.net2.nerim.net [62.4.19.30])
by mallaury.noc.nerim.net (Postfix) with ESMTP id BE97F6308A
for <[EMAIL PROTECTED]>; Thu, 21 Nov 2002 13:00:13 +0100 (CET)
Message-ID: <[EMAIL PROTECTED]>
From: Vincent Caron <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a)
Gecko/20020910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [NGL-devel] Re: [ngl-cvs] removed not so smart pointers. renamed
nuiSmartRef
to nuiRefCount and moved it to its own header file....
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Thu Nov 21 04:01:08 2002
X-Original-Date: Thu, 21 Nov 2002 13:00:25 +0100
Sebastien Metrot wrote:
> *Commit from /meeloo/* 2002/11/21 03:25:41
>
> ------------------------------------------------------------------------
>
> removed not so smart pointers. renamed nuiSmartRef to nuiRefCount and
> moved it to its own header file.
> adapted nuiTexture to these changes
/me applause
Received: from mallaury.noc.nerim.net ([62.4.17.82])
by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 18GhON-0005iT-00
for <[EMAIL PROTECTED]>; Tue, 26 Nov 2002 07:12:51 -0800
Received: from zerodeux.net (mksp.net2.nerim.net [62.4.19.30])
by mallaury.noc.nerim.net (Postfix) with ESMTP id 6909962F81
for <[EMAIL PROTECTED]>; Tue, 26 Nov 2002 16:12:34 +0100 (CET)
Message-ID: <[EMAIL PROTECTED]>
From: Vincent Caron <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913
Debian/1.1-1
MIME-Version: 1.0
To: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [NGL-devel] NUI build pb
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Tue Nov 26 07:13:06 2002
X-Original-Date: Tue, 26 Nov 2002 16:12:36 +0100
- new 'nui_all.h' includes nuiSlider.h which is not in the repository
- including 'nui_all.h' is maybe good for MSVC's pch, but not an option
for other compilers. Please guard nui_all.h including in nui.h from
other compilers than MSVC. BTW, there's no such #include "ngl_all.h" in
NGL and PCHs seems to work fine, why is this needed in NUI ?
- some recent files (like nuiDragAndDrop.h and nuiRefCount.h) have the
execute bit set in the repository. I'll fix them, but that would be cool
to know why they have this bit set in the first place ...
Received: from ivsweb.net2.nerim.net ([62.212.112.100] helo=ivssbs.IVSDOMAIN.FR)
by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 18Gi0z-0006hw-00
for <[EMAIL PROTECTED]>; Tue, 26 Nov 2002 07:52:46 -0800
Received: from harry ([192.168.0.54]) by ivssbs.IVSDOMAIN.FR with Microsoft
SMTPSVC(5.0.2195.5329);
Tue, 26 Nov 2002 16:56:40 +0100
Message-ID: <[EMAIL PROTECTED]>
From: "Sebastien Metrot" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Subject: Re: [NGL-devel] NUI build pb
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 26 Nov 2002 15:56:40.0546 (UTC)
FILETIME=[68B07C20:01C29564]
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Tue Nov 26 07:54:06 2002
X-Original-Date: Tue, 26 Nov 2002 16:49:39 +0100
----- Original Message -----
From: "Vincent Caron" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, 26 November, 2002 16:12
Subject: [NGL-devel] NUI build pb
> - new 'nui_all.h' includes nuiSlider.h which is not in the repository
>
I'm fixing this on the mac.
> - including 'nui_all.h' is maybe good for MSVC's pch, but not an option
> for other compilers. Please guard nui_all.h including in nui.h from
> other compilers than MSVC. BTW, there's no such #include "ngl_all.h" in
> NGL and PCHs seems to work fine, why is this needed in NUI ?
>
I admit this to be strange and I'm not sure I understand the thing totaly.
Anyway, it seems that building PCHs thru ngl.h is enough as all the overhead
is in Windows.h and related headers. I tried including ngl_all.h at the end
of ngl.h and things started to break everywhere because of nglKeyboard.h so
I removed it. Anyway, 20 to 40 seconds to compile NGL is fast enough for me
and I don't plan to take much more time trying to squeeze seconds out of the
compiler. In nui we don't have the same problem with nglKeyboard so I
included ngl_all.h. I'll add guards as it seems to kill gcc (at least on my
Mac, which didn't needed this...).
> - some recent files (like nuiDragAndDrop.h and nuiRefCount.h) have the
> execute bit set in the repository. I'll fix them, but that would be cool
> to know why they have this bit set in the first place ...
>
I really don't know. All the files have the exact same rights on my dev
machine (700) and I really didn't changed anything concerning this.
