nanogui: Thread: re:

I completely agree with setting up the frame buffer device.  It's a pain in the ass.

I am looking for someone to write an svgalib driver for nanoX, now that it's
easy to add drivers.  This will allow nanoX to run on all those millions of Linux
systems that are still running < 2.2 kernels...  svgalib also supports mice.

I've got a long list of features too.  But nanoX is still **very** primitive.  I am
going to be writing a window manager soon, but I have some big API issues
that need to be discussed.  

Currently, I am concentrating on getting nanoX so that it can be readily
customized for multiple operating systems, with drivers easily added. 
The upper level api work will be next, as that gets into how we'll integrate a window
manager, and what the look-and-feel should be like.

I've been on an extreme coding binge, with no stopping yet planned...

Greg

On Monday, May 10, 1999 11:12 AM, Vidar Hokstad ####@####.#### wrote:
> On Mon, 10 May 1999, Greg Haerr wrote:
> 
> > Fellow NanoX interested parties:
> > 
> > I have today finished work on nanoX version 0.3, which includes the following features:
> > 
> > 	o completely seperate driver api and drivers for screen, mouse and keyboard.
> > All drivers are in a drivers/ subdirectory.  It's really easy to write a driver set for some
> > strange box, providing you know how the strange box's low-level graphics code should
> > work.
> 
> Wow..
> 
> I looked at nano-X a few days ago, and almost dismissed it due to the
> problems I had getting the framebuffer device up and running on my
> machine (I've got a S3 Trio card... One of those that _doesn't_ work with
> vesafb, arg.), and the mess in the graphics driver code at that time.
> 
> Guess this means will almost certainly use nano-X for our Linux based
> set-top box/ webpad type machine.
> 
> I've got a long list of features I'd like, and if nano-X keeps improving
> at this rate we'll be putting at least one full time developer on helping
> out with further development.
> 
> And one of the requirements we have, is that we need to port Mozilla to
> whatever graphics library we use - we plan to allocate people to that
> too... :)
> 
> Keep up the good work!
> 
> Regards,
> 
> Vidar Hokstad ####@####.####
> Director of R&D, Screen Media AS
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> [

No, the hotspot is relative to the image itself.  The upper level routines
don't check hotspot negative relativity before erasing the cursor.  

The cursor is always clipped if a graphics draw request intersects with the cursor.
If there's no interesection, then you're right, it's not undrawn.

Greg

On Monday, May 10, 1999 12:00 PM, Alan Cox ####@####.#### wrote:
> > 	Well, I understand that, except that with negative hotspot
> > numbers, the graphics subsystem can't create proper "cursor clipping bounding
> > boxes" for the mouse cursor.  In other words, when graphics output
> 
> Umm.. the hot spot doesnt matter surely. Your hot spot can be the other side
> of your desk even, its not drawn so doesnt need clipping ?
> 
> The DOS port is funny btw. Maybe we will get Gtk for DOS next 8)
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

> -----Original Message-----

> I completely agree with setting up the frame buffer device.  It's
> a pain in the ass.

This I'm, personally, yet to look at.

> I am looking for someone to write an svgalib driver for nanoX,
> now that it's easy to add drivers.  This will allow nanoX to
> run on all those millions of Linux systems that are still
> running < 2.2 kernels...  svgalib also supports mice.

This was my first/next port of call.  I have never tired anything on SVGAlib
yet, and thought this would b e a "fun" place to start.

> I've got a long list of features too.  But nanoX is still
> **very** primitive.  I am going to be writing a window
> manager soon, but I have some big API issues that need
> to be discussed.
>
> Currently, I am concentrating on getting nanoX so that it can be readily
> customized for multiple operating systems, with drivers easily added.
> The upper level api work will be next, as that gets into how
> we'll integrate a window
> manager, and what the look-and-feel should be like.

Someone just offered me an old Mac - almost tempting to grab it just for the
fact I don't think we have any MAC's on the list.

> I've been on an extreme coding binge, with no stopping yet planned...

You say this like it's a bad thing.tm

	-Darran

Hi Greg,

it really looks good, how the Nano-X improves. And it's really cool to
see someone hacking enthusiasticly like you ... 8-)

Just my two cents:

As this thing is called Nano-X, it should stay nano. If you can keep up
with a modular approach, this is okay, but please don't include features
that aren't removable afterwards.

The windowmanager should be modular, too. For example one windowmanager
for big displays with borders and titlebars, and one windowmanager for
PDAs, where only one window stays in front.

In about 2 weeks I gonna start to do a toolkit upon this little thingy,
except someone else has already started one ... ?

- alex

On Mon, 10 May 1999, Greg Haerr wrote:

> I completely agree with setting up the frame buffer device.  It's a pain in the ass.
> 
> I am looking for someone to write an svgalib driver for nanoX, now that it's
> easy to add drivers.  This will allow nanoX to run on all those millions of Linux
> systems that are still running < 2.2 kernels...  svgalib also supports mice.
> 
> I've got a long list of features too.  But nanoX is still **very** primitive.  I am
> going to be writing a window manager soon, but I have some big API issues
> that need to be discussed.  
> 
> Currently, I am concentrating on getting nanoX so that it can be readily
> customized for multiple operating systems, with drivers easily added. 
> The upper level api work will be next, as that gets into how we'll integrate a window
> manager, and what the look-and-feel should be like.
> 
> I've been on an extreme coding binge, with no stopping yet planned...
> 
> Greg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

Alexander Peuchert
####@####.####
http://www.peuchert.de ( not very interesting yet ;-) )

On Tue, 11 May 1999, Alexander Peuchert wrote:
> As this thing is called Nano-X, it should stay nano. If you can keep up
> with a modular approach, this is okay, but please don't include features
> that aren't removable afterwards.
> The windowmanager should be modular, too. For example one windowmanager
> for big displays with borders and titlebars, and one windowmanager for
> PDAs, where only one window stays in front.

I agree. It'd be nice to have one which has a similar feature set to the
better X ones (multiple desktops, iconisation, toolbars, menus when you
right click on the desktop, background graphics, etc.), and one which has
a similar feature set to EPOC for PDAs where space is limited. The latter
would have to also be controllable entirely from the keyboard, for where a
touchscreen/pad is unavailable or inconvenient.
 
> In about 2 weeks I gonna start to do a toolkit upon this little thingy,
> except someone else has already started one ... ?

I don't think they have. Were you thinking of starting from scratch or
porting something like GDK to it? Several new features will need to be
added to nano-X before a GDK port could be completed.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Tue, 11 May 1999, Alex Holden wrote:

> > In about 2 weeks I gonna start to do a toolkit upon this little thingy,
> > except someone else has already started one ... ?
> 
> I don't think they have. Were you thinking of starting from scratch or
> porting something like GDK to it? Several new features will need to be
> added to nano-X before a GDK port could be completed.

Well, firstly I think of porting the W toolkit to nano-X. Because its
small, about 150k. As stated in a previous mailing, I'd support to
directly provide a GDK interface for nano-X. It's less complicated than X
and there would be many apps for it.

A second toolkit,  besides GTK, would be needed for smaller comps like
PDAs.


> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 

- alex

Alexander Peuchert
####@####.####
http://www.peuchert.de ( not very interesting yet ;-) )

On Tue, 11 May 1999, Alexander Peuchert wrote:
> Well, firstly I think of porting the W toolkit to nano-X. Because its
> small, about 150k. As stated in a previous mailing, I'd support to

Cool, I'd like to see that.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

Please excuse my ignorance, but where can I find info on the W toolkit?

Reagen

Alex Holden wrote:
> 
> On Tue, 11 May 1999, Alexander Peuchert wrote:
> > Well, firstly I think of porting the W toolkit to nano-X. Because its
> > small, about 150k. As stated in a previous mailing, I'd support to
> 
> Cool, I'd like to see that.
> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

try http://www.students.tut.fi/~t150315/

what is your interest ?

alex

On Tue, 11 May 1999, Reagen Ward wrote:

> Please excuse my ignorance, but where can I find info on the W toolkit?
> 
> Reagen
> 
> Alex Holden wrote:
> > 
> > On Tue, 11 May 1999, Alexander Peuchert wrote:
> > > Well, firstly I think of porting the W toolkit to nano-X. Because its
> > > small, about 150k. As stated in a previous mailing, I'd support to
> > 
> > Cool, I'd like to see that.
> > 
> > --------------- Linux- the choice of a GNU generation. --------------
> > : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> > -------------------- http://www.linuxhacker.org/ --------------------
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ####@####.####
> > For additional commands, e-mail: ####@####.####
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

- alex

Alexander Peuchert
####@####.####
http://www.peuchert.de ( not very interesting yet ;-) )

I've been working on a solid-state general purpose micro-server for a
while, and it needs a decent (but very tight) management interface. 
So.. I'm always looking for ideas.

Reagen

Alexander Peuchert wrote:
> 
> try http://www.students.tut.fi/~t150315/
> 
> what is your interest ?
> 
> alex
> 
> On Tue, 11 May 1999, Reagen Ward wrote:
> 
> > Please excuse my ignorance, but where can I find info on the W toolkit?
> >
> > Reagen
> >
> > Alex Holden wrote:
> > >
> > > On Tue, 11 May 1999, Alexander Peuchert wrote:
> > > > Well, firstly I think of porting the W toolkit to nano-X. Because its
> > > > small, about 150k. As stated in a previous mailing, I'd support to
> > >
> > > Cool, I'd like to see that.
> > >
> > > --------------- Linux- the choice of a GNU generation. --------------
> > > : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> > > -------------------- http://www.linuxhacker.org/ --------------------
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: ####@####.####
> > > For additional commands, e-mail: ####@####.####
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ####@####.####
> > For additional commands, e-mail: ####@####.####
> >
> 
> - alex
> 
> Alexander Peuchert
> ####@####.####
> http://www.peuchert.de ( not very interesting yet ;-) )
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####