[<<] [<] Page 2 of 3 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE:
From: Greg Haerr ####@####.#### Date: 11 May 1999 19:00:15 -0000 Message-Id: <01BE9BAE.73E561E0.greg@censoft.com> 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... 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? Greg On Tuesday, May 11, 1999 1:20 AM, Alexander Peuchert ####@####.#### wrote: > 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 ;-) ) > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE:
From: Vidar Hokstad ####@####.#### Date: 11 May 1999 20:06:18 -0000 Message-Id: <Pine.LNX.4.10.9905112054540.2715-100000@a.ncg.net> 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... Why not do the same as with the display "devices": Use a jump table. That way it's a minor issue to add a compile time option for including code that uses dlopen()/dlsym() to load an external module for those that prefer that to linking in a window manager at compile time. > 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? I agree.. Just one issue: Make sure the system still works fine without any window manager, the same way X does. For our use, for instance, we don't want the windows to be movable or resizable for the end user, and we don't want any visible borders stealing screen real estate, and I suspect that to be valid for a fair share of the PDA/set top box/webpad market. Vidar Hokstad ####@####.#### Director of R&D, Screen Media AS | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE:
From: klindsay ####@####.#### Date: 11 May 1999 20:18:22 -0000 Message-Id: <Pine.BSF.3.96.990511131121.25205G-100000@mocha.mkintraweb.com> On Tue, 11 May 1999, Vidar Hokstad wrote: > On Tue, 11 May 1999, Greg Haerr wrote: > > > > 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? > > I agree.. > > Just one issue: Make sure the system still works fine without any window > manager, the same way X does. > > For our use, for instance, we don't want the windows to be movable or > resizable for the end user, and we don't want any visible borders > stealing screen real estate, and I suspect that to be valid for a fair > share of the PDA/set top box/webpad market. I agree with this as well, you want just a plan blah X server going that is very small. The real Nano-X. Having window managers modular will give Nano-X Scalability. Vidar wants to use it on a PDA/Webpad, where I would like to use it as a Linux Distribution Install since it will be much smaller and faster than X. So I would like to add at some point a nice looking window manager. Nano-X could become huge! But only if people want to add a whole bunch of options to it for customization, but you can still make it very small by just using the core. Perfect for everyone. ------------------------- Kevin Lindsay Stormix Technologies Inc. 00 75 CB D4 20 AB 02 8B 2E 22 C0 E7 F3 9A 2D 72 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE:
From: Alex Holden ####@####.#### Date: 11 May 1999 22:04:08 -0000 Message-Id: <Pine.LNX.4.04.9905112248400.1368-100000@hyperspace> On Tue, 11 May 1999, klindsay wrote: > I agree with this as well, you want just a plan blah X server going that > is very small. The real Nano-X. Having window managers modular will give > Nano-X Scalability. Vidar wants to use it on a PDA/Webpad, where I would > like to use it as a Linux Distribution Install since it will be much > smaller and faster than X. So I would like to add at some point a nice > looking window manager. Nano-X could become huge! But only if people want > to add a whole bunch of options to it for customization, but you can still > make it very small by just using the core. Perfect for everyone. That's right, a small but modular core server which lets you plug in different WMs for different situations. It would be nice to have both WMs which are scaled down to fit a palmtop's memory availability and screen size, like EPOC, and ones with all the bells and whistles like Enlightenment and WindowMaker. I could see people moving away from X entirely once it becomes stable, providing we have support for GTK+ (and hence Gnome and Mozilla), and a decent Window Manager; I almost certainly will myself. --------------- Linux- the choice of a GNU generation. -------------- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : -------------------- http://www.linuxhacker.org/ -------------------- | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE:
From: Alex Holden ####@####.#### Date: 11 May 1999 22:04:13 -0000 Message-Id: <Pine.LNX.4.04.9905112240070.1368-100000@hyperspace> On Tue, 11 May 1999, Vidar Hokstad wrote: > Why not do the same as with the display "devices": Use a jump table. That > way it's a minor issue to add a compile time option for including > code that uses dlopen()/dlsym() to load an external module for those that > prefer that to linking in a window manager at compile time. I agree that would be the best way to do it. > Just one issue: Make sure the system still works fine without any window > manager, the same way X does. Of course. > For our use, for instance, we don't want the windows to be movable or > resizable for the end user, and we don't want any visible borders > stealing screen real estate, and I suspect that to be valid for a fair > share of the PDA/set top box/webpad market. Do you want no WM at all, or do you want a simple WM which always makes the main windows full screen (but presumably not the dialog boxes), and provides some means akin to alt-tab which lets you switch between them, and a "menu" button which brings up a control panel? --------------- Linux- the choice of a GNU generation. -------------- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : -------------------- http://www.linuxhacker.org/ -------------------- | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE:
From: Alex Holden ####@####.#### Date: 11 May 1999 22:05:42 -0000 Message-Id: <Pine.LNX.4.04.9905112233100.1368-100000@hyperspace> 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... That's only one side of the story. A lot of people (myself included) _like) the fact that there are a million and one different window managers, most of them extremely configurable (and more recently, themeable), to play with. People keep saying that "users want the interface to always look exactly the same so that they only need to learn it once", but to me that's just plain boring. The fact that Motif is non-free did the most damage, IMO. Only now with modern widget sets like GTK+ can you really produce a _decent_ looking X app. > 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? X is _really_ big and bloated. Just adding a versatile set of hooks to Nano-X which allow you to link in a decent WM if you want isn't going to cause a significant amount of bloat. --------------- Linux- the choice of a GNU generation. -------------- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : -------------------- http://www.linuxhacker.org/ -------------------- | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE:
From: Vidar Hokstad ####@####.#### Date: 11 May 1999 22:36:20 -0000 Message-Id: <Pine.LNX.4.10.9905112325450.2715-100000@a.ncg.net> On Tue, 11 May 1999, Alex Holden wrote: > Do you want no WM at all, or do you want a simple WM which always makes > the main windows full screen (but presumably not the dialog boxes), and > provides some means akin to alt-tab which lets you switch between them, > and a "menu" button which brings up a control panel? No WM at all would be the best for us. We _do_ want multiple windows on screen at the same time, but we want the software - not the user - to have full control over movement, resizing, mapping and unmapping etc. For us, having a windowing system instead of drawing on a raw framebuffer device etc. is just a matter of convenience from a software development standpoint - the user won't see much of it. Our device isn't really meant to be perceived as a computer by the end user, but an appliance... An "alt-tab" function would be great for more generic functions, but in our case we'd have to disable it, as well as any menu buttons. But by all means, any features that's easy to disable is a good feature :-) Vidar Hokstad ####@####.#### Director of R&D, Screen Media AS | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE:
From: Greg Haerr ####@####.#### Date: 11 May 1999 22:39:21 -0000 Message-Id: <01BE9BCD.202F14F0.greg@censoft.com> On Tuesday, May 11, 1999 3:58 PM, Alex Holden ####@####.#### wrote: > 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... > > That's only one side of the story. A lot of people (myself included) > _like) the fact that there are a million and one different window > managers, most of them extremely configurable (and more recently, > themeable), to play with. People keep saying that "users want the > interface to always look exactly the same so that they only need to learn > it once", but to me that's just plain boring. The fact that Motif is > non-free did the most damage, IMO. Only now with modern widget sets > like GTK+ can you really produce a _decent_ looking X app. I agree. Except that most of the work in writing window managers (except for the expose event/z-order calculations, which is handled "internally" in the X model) is writing all the code to draw the good-looking window frames, etc. But in the nano project, it's really a moot issue, since we're all in agreement that at least the draw-code side of the window manager needs to be available as a detachable api that would allow anyone to code their own look and feel, should they really find the time and energy to do it. I'm actually in favor, stated in another email, that we don't get locked into *any* window management theology at the mid-level api's for nanogui, so that the nanogui graphics engine could be used, for example, for my nano-win32 project. ;-) In another email, I will propose a development track for nanoX v0.4: separation and identification of this "mid-level" api from the user-level X-like api's now present in nanoX. By creating this api early, various folks on this mailing list could start out feasability testing certain concepts, like whether or not nanoX should/could support GDK directly, or whether it's built on top of nanoX. Getting more developers in the game will help us determine how much more work the base nanogui graphics engine needs to support the "cool stuff." Greg > > > 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? > > X is _really_ big and bloated. Just adding a versatile set of hooks to > Nano-X which allow you to link in a decent WM if you want isn't going to > cause a significant amount of bloat. Agreed. > > --------------- Linux- the choice of a GNU generation. -------------- > : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : > -------------------- http://www.linuxhacker.org/ -------------------- > > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: re:
From: Greg Haerr ####@####.#### Date: 11 May 1999 22:51:28 -0000 Message-Id: <01BE9BCE.D1ECADF0.greg@censoft.com> Alan, In the middle of my sleep last night I finally realized what you are talking about, and you are right: the hotspot doesn't matter, since it's not drawn. The problem is that the bogl libraries relocate the drawn cursor image by offseting from the x,y hotspot, and I was then stating that the image drawing location then was concerned with the hotspot. 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... Greg On Monday, May 10, 1999 12:34 PM, Greg Haerr ####@####.#### wrote: > 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: ####@####.#### > > > > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: re:
From: Ben Pfaff ####@####.#### Date: 12 May 1999 01:21:18 -0000 Message-Id: <877lqfjcoo.fsf@pfaffben.user.msu.edu> 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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 2 of 3 [>] [>>] |