The Nano-X Window System

Found this

http://microwindows.censoft.com/

@LiveForIt

Erm! Don't you have other things to do at the moment?

@Antique

Quote:
Ooohh, a Sekrit?

Spoil it, spoil it!

edit: english, difficult me talk

Hi @LiveForIt

Is there a FLTK - FastLightToolKit plotted in the future of X11?
...Earth calling Edgar...!

@Snuffy

The Nano-X Window System works on SVGALIB.

I'm porting SVGALIB right now.

@Snuffy

Do you mean this FLTK on os4depot ?

@Snuffy

My reply from outer space:

FLTK is already compiled and works well. Is one of the few projects, which
compiles without any change. Do you need a special program?

@LiveForIt

I'd be easier just to write a minimal emulation library for SVGALib I'd have thought.

When I've ported SVGALib stuff in the past I've just opened an Intuition screen/window and converted the calls to graphics.library.

Hi cygnusEd,
You sure are an intersting looking alien!
The OS4 FLTK version is kind of behind the times and features:
' The Amiga version is a WIP but it's almost complete, it offers all the
functionality of the official 1.1.6 version, (2005)'
Nano-X Windows=FLTK v1.0.11, and FLTK v1.1.3
Do you need a special program?
Nope! Just curious about FLTK's WIP progress.

Hi TSK,
Yes, but since the OS updates, it doesn't fly anymore for me. Is it working for you?

Hi @LiveForIt
I'm porting SVGALIB right now.
Nice, thanks!

Hi all,
Have a happy Thanksgiving 2007! A long weekend holiday starts ... :)

@Chris

Yes,

what I'm doing is using the svgalib sourcecode as bases, what I have done is strip out the stuff that does not work, and add stuff that does,

I'm using a P96 screen mode, 8bit graphics ends up in graphics.library, 15/16/24/32 bit ends up in picasso96 routines, in some cases the original svgalib routines are used, by supporting linear addressing, page mode is not supported, only linear mode, to much hassle to support page mode.

event raw keyboard, mouse events is wrapped on top of User-Port (MsgPort), joystick routines end-up in some dummy routines, (Amiga Input is to buggy for my taste)

@LiveForIt

Oh... make sure you send me a version of SVGALib as soon as you're done! Lot's of stuff out there to port that uses it! =)

@TSK

I have never managed to make use of the current version of FLTK on os4depot... i've compiled some stuff, but they don't work as they should...

@Snuffy

I've compiled V 1.1.7 (17.Jan.2006), which is the latest stable version.
Because of X11 it works better than the native version.

There is also a 2.0 version, but it is under development.

@spotUP

It will be available on os4depot when I think it ready, I was thinking about you when I started porting SvigaLib.

Currently the event handler is almost complete.

* Mouse support works
* Raw keyboard support work

Time out for event handler is on my todo list.

Every thing that renders in to direct-video that uses linear mode looks ugly, (but totally viewable), all screen modes reports support for linear mode.

I will try to force P96 commands when vgagl commands renders in to screen bitmaps, and normal vgagl routines when rendering in to virtual contexts, this should solve some of the problems.

Palette does not auto update, don?t know way, pressing Amiga + M a few times and palette is ok

Svgalib programs crash on exit
(I think this has some thing to do whit the newly written event handler support)

Some of the examples use alloca() and they eat up all the stack in second, I will rewrite some of the examples, to they will use AllocVec(), and I also try rewrite all fork() based examples to use Dos.library / CreateProc() and signalling, besides that I will try to make all examples safer, the original examples crash if they fail to open video modes

@LiveForIt

Oh.. I'm flattered =)
I hope you can fix the remaining issues.
If not, ask for help on utilitybase.com or in #amigadev.

@spotUP

Yesterday I head a 3 days set back, some of files where corrupted (vga.c some makefiles, videomode conversion list), I have managed to do 2 days works in just one day, writing from memory.

I have also come up whit smart script should keep my source code safer from data corruption,

Goes like this

; start of script
.bra {
.ket }
.key name

If not exists backup:.source_backup
Makedir backup:.source_backup
Endif

If exists backup:.source_backup
If exists {name}
Copy {name} backup:.source_backup
Endif
Endif

Run <>nil: notepad {name}
; End of script

I have also added this line to shell-startup

Alias ed s:backup_notepad

@LiveForIt

and what happens if you edit an already corrupted
file?

@pvanni

Yes it looks like I need to create directory whit current date, and store the files inn there.

@LiveForIt

or setup subversion and making chekins when you make
substantial changes on yours sources, this way you
can retreive old version, put comments and compare
differt version and much, much more.

@pvanni

if I do not remember to update version number that will also be a problem, reviving old versions is not that important to me, I do not make mistakes

The most important thing her is to find none corrupted files,

Hemm,. Maybe I do the date archiving in user-startup, that way can keep different versions, it can be done by simply renaming the directory, maybe numbering the directories.

For example if backup number 10 exits, and a new backup 1 exits,
delete backup 10, Rename backup 9 to backup 10, rename backup 8 to 9, etc,

This way I can keep files for x number of reboot, so disk does not fill up whit crap.