nanogui: Thread: re:

Hi Greg,

On Tue, 11 May 1999, Greg Haerr wrote:

> I agree that the window mgr should be modular, but if you want different window
> managers, you might as well use X.   Actually, although it was a good idea,
> the fact that X's design allowed for so much flexibility with differing looks and feels
> contributed to Microsoft's taking over with their faster, more consistent gui...

No, not what I meant. I think, there is a need for at least two different
windowmanagers. One for a large display, like 640x480. Normal activities
there, like title-bars, overlaping windows, ...
And one for small displays. Just one window filling the complete screen,
plus a taskbar. This is a must for PDAs and embedded devices. or would you
like to click on a 4x4 point small close button?

> 
> The first version of nanoX that I write will definitely have some built-in window
> management, in order to keep it small.  In my opinion, *all* of nanoX should be
> kept small, so that it can be used where X can't.  Otherwise, why not just use X?

Me too. That's why nano-X is needed. For bigger installations, X is
already there. But as with INTEL and M$, the requirements are getting
higher year by year. GTK and GNOME or KDE, for example, need more
resources. So, I see nano-x as a window system for small or out-dated
computers.
If I project that in to the future, in two years, the standard desktop
computer will be a Pentium 5 with about 512 MB. And the PDAs and embedded
thingies will have the speed of the computers today. So, at that time,
nano-x will still have to be small, but in other dimensions ...

> 
> Greg
> 

- alex

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

Ben - before you make too many changes in BOML, lets talk.  The proper management
of cursor hotspots is a tricky issue, and I've been thinking about some ideas as to
which layer should deal with them.  For now, I've just made the hotspot 0,0 in arrow.c
so that no other code needs to be modified...

Greg

On Tuesday, May 11, 1999 7:32 PM, Ben Pfaff ####@####.#### wrote:
> Greg Haerr ####@####.#### writes:
> 
> 	   The correct answer is that no drawing routines should concern themselves
>    with the hotspot cursor location; this is not a draw issue, it's an intersection issue
>    for events, etc.  Thus, the bogl libraries should remove any hotspot offset adjustment
>    from the low-level bogl_pointer draw routine...
> 
> Okay, that shouldn't be a problem.  I guess you're right, it is a bit
> of a layering violation, but it worked well with my BOML mouse
> interface.  I'll make a change in newer versions.
> 

Greg Haerr ####@####.#### writes:

   Ben - before you make too many changes in BOML, lets talk.  The proper management
   of cursor hotspots is a tricky issue, and I've been thinking about some ideas as to
   which layer should deal with them.  For now, I've just made the hotspot 0,0 in arrow.c
   so that no other code needs to be modified...

Okay, keep talking, I'll hold off.  Today I'm working on code that I'm
being paid for, anyway, or at least after I get GNU Checker working
with glibc 2.1.
-- 
"While the Melissa license is a bit unclear, Melissa aggressively
 encourages free distribution of its source code."
--Kevin Dalley ####@####.####

 
: I just want to destroy the window, not to exit the program.
: Any sugguest?

What happens if you add the following to your wndproc:

case WM_CLOSE:
    DestroyWindow(hwnd);
    return 0;
...

> Compiling nanox.c ...
> arm-linux-gcc -c  -DNANOX=1 -DMWPIXEL_FORMAT=MWPF_PALETTE -DVTSWITCH=1
> -DHAVE_FILEIO -DHAVE_BMP_SUPPORT=1 -DHAVE_GIF_SUPPORT=1 -DHAVE_XPM_SUPPORT=1
> -DHAVETEXTMODE=0 -DLINUX=1 -DUNIX=1  -I../include -I.
> -I/home/roni/microwindows-0.90/src/include -Wall -Wpointer-arith -O3
> -mstructure-size-boundary=8 -o nanox.o nanox.c
> 
> I need to see what the gcc command line is when building libraries,
> this should be further down the make.
> 
Hi Greg and all you!

I have some things to the problem of the dynamically linked files. As you 
remember, I have set SHAREDLIBS=NO in my config file, but I got dynamically 
linked files after compiling. 
After that I set LDFLAGS += -static in the Arch.rules file. But in this case I 
get the following error while compiling nxroach.c:

Compiling nxroach.c ...
nxroach.o: In function `main':
nxroach.o(.text+0x170): undefined reference to `sin'
nxroach.o(.text+0x184): undefined reference to `cos'
collect2: ld returned 1 exit status
make[2]: *** [/home/roni/microwindows-0.90/src/bin/nxroach] Error 1
make[1]: *** [subdir-nxroach] Error 2

After removing nxroach.c, microwindows can be compiled perfectly.
Then I wanted to compile with freetype1. And I got the same error when 
compiling font_freetype.c: undefined reference to 'sin' and 'cos'. I have 
made a comment from the freetype_setfontrotation function which is using the 
sin and cos functions, and I could compile (and use) the freetype fonts. What 
could be the problem with 'sin' and 'cos'? 
Thank you for your help in advance!

Áron Takács

Thanks, Jon!

In case of nxroach I have done it:

When in the Makefile of nxroach is written:

# Linking flags
LDFLAGS += -lm
and
######################## Tools targets section ###############################
$(TOP)/bin/nxroach: $(OBJS) $(NANOXCLIENTLIBS) $(TOP)/config
	$(CC) $(CFLAGS) $(LDFLAGS) $(OBJS) -o $@ $(NANOXCLIENTLIBS)

I get the same error. But I can get nxroach to compile by modifying the 
Makefile as follows:

# Linking flags
LDFLAGS += 
LIBM = -lm
and
######################## Tools targets section ###############################
$(TOP)/bin/nxroach: $(OBJS) $(NANOXCLIENTLIBS) $(TOP)/config
	$(CC) $(CFLAGS) $(LDFLAGS) $(OBJS) -o $@ $(NANOXCLIENTLIBS) $(LIBM)

But how to do the same in case of font_freetype.c?

Áron Takács

>   Also let me know i am not able to see successful results when i try to 
> compile my keyboard test application or the framebuffer test application.

I have no idea what's wrong, given the sparse info/error messages you've 
supplied.


> Is it because i am testing my application  over the hyperterminal.

Make sure your kernel is booting in framebuffer mode.


> Our FPGA board also has a VGA port.Can u suggest me something so that i am 
> able to see the kernel log messages on the monitor.

That's a linux kernel/configuration issue, try a linux mailing list.

Regards,

Greg