[<<] [<] Page 3 of 3 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE:
From: Alexander Peuchert ####@####.#### Date: 12 May 1999 07:24:18 -0000 Message-Id: <Pine.GSO.4.02.9905120909550.29299-100000@rumburak> 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 ;-) ) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: re:
From: Greg Haerr ####@####.#### Date: 12 May 1999 15:28:11 -0000 Message-Id: <01BE9C59.59BE51E0.greg@censoft.com> 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. > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: re:
From: Ben Pfaff ####@####.#### Date: 12 May 1999 15:38:22 -0000 Message-Id: <873e12jnra.fsf@pfaffben.user.msu.edu> 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 ####@####.#### | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re:
From: "Greg Haerr" ####@####.#### Date: 7 Sep 2000 07:21:45 -0000 Message-Id: <017301c0189c$613c9920$15320cd0@gregh> : 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; ... | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re:
From: Takács ####@####.#### Date: 27 Apr 2004 08:27:21 +0100 Message-Id: <200404270926.58818.takacs.aron@infracont.hu> > 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [nanogui] Re:
From: Takács ####@####.#### Date: 27 Apr 2004 11:05:23 +0100 Message-Id: <200404271204.57674.takacs.aron@infracont.hu> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re:
From: "Greg Haerr" ####@####.#### Date: 27 Sep 2008 16:59:18 -0000 Message-Id: <20a501c920c2$0ffddf10$6501a8c0@winXP> > 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 3 of 3 [>] [>>] |