[Fluxus] GLFW?

[Dan Wilcox]

It dosen't depend on GL 3+, it only supports it. You can create GL 2 contexts if you want, you're just not going to be able to take advantage of newer hardware stuff.

The clipboard code is in 2 functions with platform specific implementations which could be reused, but why reinvent the wheel. We've moved OpenFrameworks to GLFW on the desktop in the new version and it seems to be going well so far.

Telbat ym morf tnes.

---------------
Dan Wilcox
danomatika.com
robotcowboy.com

On Aug 7, 2013, at 9:01 PM, Kassen <signal.automatique at gmail.com> wrote:

> On Wed, Aug 07, 2013 at 01:27:50AM -0400, Dan Wilcox wrote:
>>   Howdy all,
>>   Apologies if this has come up before, but is there any interest in
>>   upgrading fluxus from GLUT to GLFW?
>>   GLFW version 3 has multi-window, multi-context, & openGL ES support not to
>>   mention copy to/from system clipboard (great for the scratchpad). The GL
>>   ES support means Fluxus could run on the Raspberry Pi natively without X
>>   which would be quite cool. I did check and racket is available as a
>>   Raspbian (RPI+Debian) package.
> 
> A quick search informed me that it supports joysticks too; there would
> be some real value in that especially if that would be cross-platform.
> Cross-platform joystick support can be a issue as our friends in the
> SuperCollider world saw. If it can run without X on a Pie it might
> also be able to on a desktop/laptop; that might make sense to cut down
> complexity in installations where we may not need a desktop
> environment/windowing system/etc at all and those just create
> complexity; I know I am not the only one who sometimes sets up
> computers wit a .xsession that merely loads Fluxus in full-screen; it
> seems rather wasteful to have a whole X stack in that case.
> 
> On the downside; it depends on OpenGL3.0 and up, which I just read was
> released in 2008, only 5 years ago. I am personally in favour of
> re-using old computers. This -to me- makes sense both from a
> environmental point of view and from the perspective of enabling low
> budget artists to create works without the need to ask for support or
> approval. Hardware from 5 years ago is quite capable of doing
> interesting things.
> 
> Being able to get to the clip-board is not such a big issue to me;
> there are utilities for that that a Racket or C++ call to the system
> should be able to reach. I am not sure why we didn't yet integrate
> that with Ctrl+c/v (or Command + c/v, as the case might be) yet; it
> should be fairly straightforward.
> 
> I don't know enough about it to voice a opinion either way but these
> are the concerns that stand out to me most right now.
> 
> Yours,
> Kas.