Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Resources for Rolling Your Own Windowing System? 279

Posted by Cliff from the be-your-own-GUI dept.
WalterGR asks: "There are plenty of resources available for writing operating systems, e.g. Tanenbaum's Modern Operating Systems, the Dinosaur Book, and countless web sites. For those of us who aren't interested in low-level issues, and prefer focusing on human-computer interaction, what resources are available for designing windowing systems (a la X Window)? Issues like the object hierarchy, event management, modularity, redefining behavior at runtime (e.g. for skins) etc. Any suggestions?"
This discussion has been archived. No new comments can be posted.

Resources for Rolling Your Own Windowing System? More

Resources for Rolling Your Own Windowing System?

Comments Filter:

  • OWL, MFC, K, etc. (Score:5, Informative)

    by Anonymous Coward on Thursday January 10, 2002 @06:23PM (#2819879)
    Take a look at the object windowing libraries put out by several vendors. It should give you a good footing on developing your own object hierarchy.

    As for not getting into 'low-level' stuff, you're SOL if you want to build an X-like system.
    • OWL and MFC were both written to create an OO shell around the pre-existing Windows window-management stuff. In a sense, they are hacks, not clean-sheet designs. As a result, they have some rather odd characteristics (well, at least MFC does - I haven't used OWL).

      So it may be that someone interested in starting from scratch on a new, OO-based windowing system would be better served by studying something else, like Java's AWT or Swing.

  • Windowing system or window manager? (Score:3, Insightful)

    by Indomitus ( 578 ) on Thursday January 10, 2002 @06:26PM (#2819896) Homepage Journal
    First you need to ask yourself if you really want to recreate the XWindows System or if you want to create a window manager like Enlightenment, fvwm, etc. If you want to recreate the years of work that has gone into X, that's your choice but I think you should look at creating a window manager, you'll probably get farther.
    • Again, I point out that X11 is a piece of turd. There is no reason that we should accept the X Window system as sacrosanct. Why does X insist that a font is a 1 bit bitmap? Why is X written for network transparent operation when 99% of the usage of a desktop windowing system is local (I'm not knocking the feature, just saying it shouldn't be the central assumption of a desktop windowing system)? Why do the features necessary end up getting strapped on like XRender in a way that leaves us with two parallel font management systems for different types of X Windows apps? While everyone agrees that diversity and choice are good, do we really need so many different widget set and toolkits, all of which are separately themeable, resulting in the most heinous looking clash of aesthetics when Qt, Gtk, and Xaw apps are used simultaneously? Why is transparency and alpha blending on the client end totally impossible in X windows? Why is X Windows so damned chatty that it blows over the internet anyway?


      While X windows is mature, and supports a lot of features, and represents (unfortunately) the repository of the vast majority of the current video support for Linux (if all the drivers for video support weren't in X land, perhaps we'd have better X Windows alternatives), that does NOT mean it is the best solution and that people shouldn't be trying to come up with something better.

      • I'm sorry about the way you feel about this.
        You seem really convinced that XWindows sucks ass. I personally have never suffered from any lacklust performance of XFree86. au contraire, Xfree86 has always been _fast_ for me. In all ways. I can also add that I use 'the evil option' (read: windows) on daily basis. Their performance is very comparable.

        For example snes9x [snes9x.com] works for me under X at same speed as in Windows. in windows it runs with OpenGL acceleration, in XFree86 it runs without acceleration at all (using 'nv' driver). Speed is roughly the same (not max, however).
        I really don't understand your comment about XW's bad performance over network. I use it for running pan [rebelbase.org] over network (10bT), and performance has been very, very nice. I have also ran netscape & opera over ssh link (10bT again) and they performed very well.

        Please do give some real examples where Xfree86's performance is inadeguate.
        • X Windows runs fine over 10bT. I said over the Internet. While the X protocol isn't very bandwidth intensive, it degrades rapidly with latency because it's fairly chatty (see for comparison Windows Terminal Server - I hate to say it, but it does a much better job at this - and I hate Windows, in general).


          Most apps that just involve pixel painting (like an emu type thing) will probably run in comparable speed, since the overhead in blitting pixels to the screen is presumably not in and of itself huge. However, see something like Mozilla, for example. Try moving the window around on and off screen. Watch the redraw of the window when it moves back on screen. Awfully slow, I must say. GUI responsiveness in general is not great in X. I mean, it's not terrible - MUCH better than it used to be on older hardware.


          In any case, you missed the entire point of my post, since it wasn't all about the performance of X Windows. Performance wise, X windows is adequate for what it does. Not terrible - but like I said, not great. This is subjective.


          Frankly, X windows is on par speed-wise with OS X (subjectively - I'm not comparing them on identical hardware), but what matters is that OS X is aesthetically much more pleasing, renders fonts beautifully, supports transparency and anti-aliasing, and the other nice things that DPS gets you. If you can get all that nicely integrated into your windowing system rather than having them as kludgy strap-ons, and at comparable performance, why not go for it?

      • Why is X written for network transparent operation when 99% of the usage of a desktop windowing system is local (I'm not knocking the feature, just saying it shouldn't be the central assumption of a desktop windowing system)?

        99% of X-Window terminals don't run on desktops. They run on Workstations, that are usually connected to very fast LANS. You may not thing transparent network operation is important at home on a 28.8k modem, but when your using it in a highly distributed production network, the fact that you can make Emacs come up on the display of a Sun from an HP since Emacs isn't installed on the Sun is one of the most useful things in the world.

        While everyone agrees that diversity and choice are good, do we really need so many different widget set and toolkits, all of which are separately themeable, resulting in the most heinous looking clash of aesthetics when Qt, Gtk, and Xaw apps are used simultaneously?

        So monopoly is good? People like different things. Let the desktop evolve.

        Why is transparency and alpha blending on the client end totally impossible in X windows? Why is X Windows so damned chatty that it blows over the internet anyway?

        LBX == Low Bandwidth X. It started as the Broadway project. When X was first designed, the chattiness wasn't a problem because there were no low bandwidth networks so this wasn't even a concern.

        Why do the features necessary end up getting strapped on like XRender in a way that leaves us with two parallel font management systems for different types of X Windows apps?

        The reason Linux has support for so many Window drivers is because of the XFree86 development team. They have done an incredible amount of work so that you can sit here and bitch. You don't have to like it, and you don't have to support it, but for god sakes, so atleast a little bit of respect for it.
        • Why is X written for network transparent operation when 99% of the usage of a desktop windowing system is local (I'm not knocking the feature, just saying it shouldn't be the central assumption of a desktop windowing system)?

          99% of X-Window terminals don't run on desktops. They run on Workstations, that are usually connected to very fast LANS.

          Like the cheap, fast lan network that connects my laptop to the machine on which this browser is running. Thin client is a very, very old concept, and by enabling me to remotely fire up and operate Mozilla on my desktop computer, it regularly saves me from flogging this portable to death by running a browser locally.

      • I think you said it yourself. X is mature. As much as it would be great to incorporate alpha-blending, there are compatibility issues to be worked through. Personally I feel that the way forward is incorporation, not replacement of X - and the place for this is by working as part of the XFree86 team. You can build an alpha-blended build whenever you want.

        As far as networkability, the reason this feature isn't being used all that much is because too many computer users have grown up on that - ah - other operating system and don't know that it can/does work and that they should be using it. The idea that an app and a display are inextricably linked in some way is totally stupid. And X efficiency beats the hell out of some of the alternatives (anyone used VNC on Windows?) and it also is application specific, rather than desktop specific. I'd use X a lot more if I could get an X server on windows (anyone got XFree to work?) but in a UNIX environment this feature really rocks.

        With regards to toolkits I do agree - there would be benefits if these could be brought together somewhat and incorporated at a lower level - but I would say that, as a lesstif/motif person.

      • There are many possible cost metrics. One puts the most value in the most commonly used cases - if 99% of all users are local, focus on them and drop remote users.

        Another valid metric tries to minimize the cost of the legitimate, but rare, users. Network transparency has a small cost, but it's critical for the people who need it.

        Yet another valid metric tries to minimize the cost of development. It is extremely cheap to develop X Windows applications in the sense that the API I learned a decade ago is still in use today. Motif has come and gone, and there are now several additional toolkits, but it's nothing like the mishmash that Microsoft has produced in the same period.

        (On a similar note, compare how little C has changed between K&R C to ANSI C9X, vs. the massive changes Visual Basic has repeatedly suffered in far less time.)

        Yet another metric tries to minimize the cost of developing new drivers. The X wire protocol is well documented, and anyone who develops a driver that speaks it (as either client or server) can be confident that their code can be widely used. Non-wire protocols tend to mutate far more quickly, either decimating the potential user base or driving up development costs.

        Put it all together, and the costs of network transparency are outweighed by its many benefits for all but the most demanding local users. And even they gain from it, albeit in more subtle ways.

        Is X perfect? Of course not, but many of the "flaws" were actually design goals for long-gone hardware. When was the last time you used a monochrome dumb terminal? The wire protocols need to be extended to reflect the fact that commodity PC prices are now far lower than dumb terminal prices - use the power of those systems! But the key word there is extending the protocols, not replacing them. E.g., make the font system more flexible.

        But at the same time, at least once a month I find I need to run an X session remotely, and I can do that from both Unix and Windows boxes. I have never been able to run Windows remotely, although I've heard that BackOrifice is pretty good for that.
      • X provides a protocol for applications to communicate with the screen.

        Contrary to popular belief, it doesn't force huge gobs of "evil network transparency" in; that pretty much comes for free.

        After all, there MUST be an IPC system involved, unless we were to transform it all into some sort of "cooperative multitasking" system with only one process (think: MS Windows, where if any bit of any application breaks, you have to reboot).

        As soon as you have IPC, extending that to allow network transparency is pretty easy, and focusing on how "expensive" this is is just silly.

        When you start with such huge misconceptions, that undermines the value of the whole discussion.

    • As an HCI student I can see the interest in writing your own window manager (I'd like to do this myself... although starting from scratch might not be the best way)

      If this is actually what you want to do, make sure that you can't customise an existing one before you start all over again - the chances are you could take a simple system like FVWM ie. something minimal, and just put a few custom toolbars and such on it.

      Try looking at the source code to other window managers. You can find several on freshmeat [freshmeat.net] that are absolutely tiny ie. a couple of hundred k. The gzipped source for aewm [red-bean.com], for example, is apparently under 50k - incredible :P

      If you're after rewriting the windowing system itself and you're doing it for HCI related reasons, I think you may be nuts. There may be a good reason to do this but it doesn't spring to mind. Whereas there are - arguably - huge numbers of usability problems with window managers in general... low consistency, little feedback, that sort of thing.
    • For those of you who ask "What's wrong with X?" think about those who said "What's wrong with Minix?" back in 1991.

      Jason.
  • Well, not exactly a resource on how to design a windowing system, but it may lead you to other pages with information on the details of windowing system implementations (especially note the alternative windowing systems)

    http://www.atai.org/guitool/ [atai.org]

  • those of us who aren't interested in low-level issues, ... (a la X Window)?
    If you aren't interested in "low-level" issues, then writing a system à la X probably won't be very interesting to you.

    Anyways, the greatest documentation of all to learn form is, was, and always will be source code [xfree86.org].

  • Just wanted to point out... (Score:4, Offtopic)

    by 2nd Post! ( 213333 ) <gundbear@pacbe l l .net> on Thursday January 10, 2002 @06:28PM (#2819909) Homepage
    That windowing systems and HCI are distinct. Windowing systems is a component of HCI, but so is command line interfaces, voice interfaces, and graphical interfaces.

    Windowing systems is one metaphor applied to graphical interfaces. HCI includes the concepts of learnability, consistent behavior, teachability, and useability.

    I'm defining learnability as the capacity for the system to teach the user, and teachability is the capacity for the system to adapt to the user.

    Windowing systems doesn't necessarily have anything to do with any of those four points unless the designer and developer choses to address those points. Themes and skins count as teachable, adaptable systems, but do not necessarily mean the system is useable, powerful, or capable.
    • A HCI idea I've been excited about for a long time is a "general interface spec"... ie. a general way to link an application to any number of interfaces.

      Just think :
      * You'd be able to twiddle kernel compile options on your interface of choice.
      * Applications suddenly become automatically accessible to the disabled.
      * Translation could be switched on (just in case the application doesn't support a particular language).
      * Interface development could SPEED ahead if a suite of decent programs are already developed.
      * Users can make choices about the bleeding-edge interfaces they use without worrying about supported applications.
      * Application developers don't have to port their wares to new interfaces.
      * From a Unix philosophy standpoint it just seems "right"... abstracting away the interface gives you a smaller more general tool.

      I've done lots of seaching for an implimentation of this idea, and probably the closest is in XML (can't remember the name unfortunately) but it's a bit limited both in functionality and available platforms.

  • rolling (Score:2, Interesting)

    by Anonymous Pancake ( 458864 )
    rolling your own windows system?

    I think I know what you guys were rolling before writing that bizarre headline.
  • People that have successfully built Windowing System are the people to ask. Odds are, there aren't more than 1% of /. readers that have successfully made an entire windowing system.

    Also, check the code of successful, open source windowing systems...

  • I'm right there. (Score:5, Interesting)

    by Ortado ( 89074 ) on Thursday January 10, 2002 @06:29PM (#2819925)
    I've been working for about 4 years now on a graphical user interface for dos as a pet project, and have learned a great number of things. So many, in fact, that i'm in the middle (still) of rewriting it. If you're intreseted, the website is http://dwin.sf.net/ [sf.net] and is open sourced. When the new version comes out (or the next preview) one could use it to see how it all fits together. This would be better then trying to use XWin to learn how everything works because it is smaller, simplier and very OOP (which is great for windowing systems). And yes, most of /. will call me crazy for reinventing the GUI, but heck, i've learned so much about computers in doing it that it's been a real fun time.

    -Jon Gentle(atrodo@atrodo.org)

  • There is little... (Score:2, Insightful)

    by ADRA ( 37398 )
    There is not a lot of information beyond some of the linux toolkit developers or Xfree / X Group, simply because this is not a very large arena, and there just isn't enough interest in creating another interface for user applications(flamebait).

    The problem is that when a user needs to write a program they have to be "aware" of your toolkit, or be unable to run on your machine.

    The result of all this has become a very constrained community of developers creating tiny visual enhancements and having the community feed off their ideas. This has been going on for > 10 years, at least. Mac's are probably the most original designers of UI system, since most company's products mimmic their styles and design elements.
  • May not be the best form of documentation, but the source code to X, window managers, and KDE/GNOME will have the answers. Got to imagine all these projects have had many different ideas implemented in each one.

  • DONT (Score:2, Insightful)

    by tjansen ( 2845 )
    No, please, not another windowing system. X11 is fine for most purposes and, if you need something is does not provide, write an extension. There are more than enough 'alternatives' that are either designed for niches [directfb.org], have never been finished [hungry.com] or will never get a significant marekt share [berlin-consortium.org]. They don't have any significant advantage, at least as a general window system, and they lack applications. And despite those people who claim that X11 is sooo bloated (usually because they see the memory usage and do not realize that most of the memory is taken by pixmaps that won't take less space in other solutions) there are proofs like TinyX [superant.com] and WeirdX [jcraft.com].

    • Re:DONT (Score:2, Redundant)

      by Fnkmaster ( 89084 )
      Sorry, this is just not true. X11 sucks. There are lots of strapped on extensions that make it suck. Writing more won't help. We need a better windowing system, rewritten from scratch for desktop use, that supports network operation without sacrificing speed, that supports transparency and vector fonts internally, that includes a widget set/toolkit as part of the windowing system.


      Just because nobody has done it yet (the only ones you point to who really tried are the Berlin folks, and they've just never had their act together, but have a lot of good concepts).


      Just look at OS X for proof that your argument is entirely irrational.

      • Re:DONT (Score:3, Interesting)

        by tjansen ( 2845 )
        >suck. Writing more won't help. We need a better
        >windowing system, rewritten from scratch for
        >desktop use, that supports network operation >without sacrificing speed,

        How do you want to improve speed? That's one of the problems. People claim that its slow, but nobody has an idea of how to make it faster without making it less secure (by letting the programs/clients access the hardware directly) or putting everything in the kernel (trading speed for stability). The only other solution I see is to reduce traffic by putting more logic on the server, and this is something already exists, it's called DisplayPostScript... of course people would have to start using it, but this is more realistic than porting appliations to a completely new system.
        And even if there was a solution to improve speed, why start something new from scratch instead of using the existing XFree and adding a new communication mechanism?

        > supports transparency and vector fonts
        > internally

        What's the advantage of saying 'this command is internally' over using an extension? There is no big difference in the X11 protocol...

        > that includes a widget set/toolkit as part of
        > the windowing system.

        The only advantage for the user (less IPC traffic) can be achieved with DPS as well. You don't need a new windowing system for this...

        > Just look at OS X for proof that your argument
        > is entirely irrational.

        OS X does not have any X11 legacy applications, and they use a DisplayPostScript variant as well. And OF COURSE they made sure that all existing applications still work on their new system.

        bye...

        • Re:DONT (Score:3, Interesting)

          by Fnkmaster ( 89084 )
          I'm sorry, I don't really understand your argument. I don't really think that "network transparency" should be part of the architecture of a desktop windowing environment at all, so I don't see what this has to do with security. When you are allowing remote apps to run on other desktops, yes, a security mechanism needs to be in place. X is slower in terms of putting pixels onto screen than any other modern desktop windowing system (i.e. Windows, Mac OS X, etc.). As in I can see Mozilla redrawing when I drag a window, even with a blazing processor, and blazing graphics card.


          With regards to "advantage of internal support for vector fonts", the advantage is that all apps would just say "draw these letters to the screen with these fonts" and the anti-aliasing, etc. would happen internally. Now, only apps written to the XRender extension do that. This means some apps support anti-aliasing, some don't. This makes my desktop ugly as sin. Also there are two parallel font management systems. This is a nightmare.


          OS X DOES support legacy X11 applications, since you can run XFree86 in rootless mode under Mac OS X. It's just that they are heinous looking compared to Aqua apps. :) I am not opposed to this kind of solution, and I'm not saying X doesn't have its uses, I'm just saying we CAN do better.


          As for your comments about DPS and the fact that OS X uses DPS as well, I am aware of that. If you are saying we could use X11 with DPS, I suppose that is true, but that seems like yet another awful hack to me. Why not just make something new and better (DPS based or otherwise) and support X11 as an add-on, or for backwards compatibility with legacy X11 apps?

          • Re:DONT (Score:3, Insightful)

            by tjansen ( 2845 )
            I don't really think that "network transparency" should be part of the architecture of a desktop windowing environment at all,

            There is not a real difference between inter-process-communication and a real network. Whatever you do with IPC can be done with a network as well.

            so I don't see what this has to do with security.

            To access the graphics hardware you need special privileges that a user-level app should not have. So you either need a server that has these priviliges (requiring IPC, the X11 way), give the app the power to access the hardware (bad idea if the user can install applications, but ok and used in some embedded solutions) or put a significant part of the windowing system in the kernel (not really recommended, but the windows way).

            With regards to "advantage of internal support for vector fonts", the advantage is that all apps would just say "draw these letters to the screen with these fonts" and the anti-aliasing, etc. would happen internally. Now, only apps written to the XRender extension do that. This means some apps support anti-aliasing, some don't.

            So what? Is your argument "the app has to be rewritten to use anti-aliased fonts, so I better rewrite it completely to use a new windowing system"? (and BTW it's usually only a matter of updating the toolkit)

            Why not just make something new and better (DPS based or otherwise) and support X11 as an add-on, or for backwards compatibility with legacy X11 apps?

            Because no user will notice the difference. Neither will most app developers who use toolkits anyway. It is just a HUGE amount of work, consider all the drivers, video support, 3D and so on, and what will be the result: nothing.
          • OS X does *not* use DPS. NeXTSTEP, OpenStep, Rhapsody, and Mac OS X Server 1.x used DPS, but Mac OS X uses Quartz, which is more-or-less Display PDF.

      • Re:DONT (Score:4, Insightful)

        by ADRA ( 37398 ) on Thursday January 10, 2002 @07:07PM (#2820177)
        Why not keep X11 the way it is, but have X11R7, or X12, which has all those dangling extensions internally as a requirement.

        It could keep almost 100% compatibility while making a "better" GUI system.

        The problem with that though is that you are forcing the user of the GUI to be a fat system. Right now, you can run X11 on an Ipaq with problem. If you start throwing the kitchen sink in as a requirement(the only way to enforce the standard), you are also abandoning a potentially large share of your market. The beauty of X11 as it is today, is that you have the choice in what you want to use, and what you don't. XFree86 does not make the pluggable nature of X11 as clear as it should be, but none the less, I like the flexability and scalability that the current system offers.
        • I am not forcing the user of the GUI to be anything. I am saying that a desktop windowing system is different from a multipurpose-network thin client windowing system, which is really what X is (err... thin X server... oh well, never mind). X assumes a dumb terminal that renders pixels as its told to. This is fine if that's what you want. What I want is a windowing system designed rationally for the 99% usage case, which is running apps locally on my desktop. Adding an X server to that is not too hard (see OroborOSX and rootless X11 support on OS X for an example).
    • We all use X11 because its there. It has always been there. When Adam and Eve got kicked out of the garden, I'm pretty sure that he took a few X11 floppies with him. Much in the Microsoft tradition, its the most used because its the only one there.

      That doesn't mean though, that it is the end all be all for windowing systems. It is at its very best in a distributed environment with many different types of machines. It is at its very worst when it is on an embedded system.

      Its all a matter of having the right tool for the job.
  • Mainly, don't be boring. There is no shortage of windowing systems that do what everyone else is doing, with a few mostly useless features and some buzzword compliance added to distinguish themselves from the pack. The easiest thing in the world to do is make a second-rate clone of an existing system, and that won't do anyone any good.

    If you want to see interesting and innovative interfaces, look at games. They are free to experiment and be unfamiliar, people even enjoy the exotic feeling of escape from the humdrum world of standard interfaces. Of course, there is more bad than good, but it's always that way where people are trying new things.

    Okay, one reference: Ask Tog [asktog.com]. Lots of good thoughts on interface design. One of his gripes stands out for me in particular: the importance of the corners of the screen in a mouse-based interface. You can always hit the corners without looking, and with a little practice, you can also hit things near the corners by "bouncing" off the corner. Radial menus out of the corners are probably the easiest thing in the world to hit reliably and quickly. Don't neglect the corners!

    Of course, this goes right out if you switch to a pen. In a lot of ways, current interfaces are much better suited to pens than to mice.
  • I think the best way to learn how X, for example works would be to use the wrox book on X Window programming and then see how that works and move from there. O'reilly also recently released a book about GUIs under the Mac platform. Also, does anyone know how microsoft does there GUI stuff? Gnome is great and all but it just seems to me that the windoes GUI is much better than gnome/kde. I dont want to start a war so i'll say that I'm a linux user nonetheless, but there must be a better way than X windows.
    • Also, does anyone know how microsoft does there GUI stuff? Gnome is great and all but it just seems to me that the windoes GUI is much better than gnome/kde. I dont want to start a war so i'll say that I'm a linux user nonetheless, but there must be a better way than X windows.

      Here's all the info you'll ever need [microsoft.com].

      Well, kind of. The Addison Wesley book on Win32 Programming isn't a bad resource either.

      Win32 is a lot like Motif conceptually (or so I'm told; I've never programmed Motif). It's also massively extensible. And, unfortunately, once you get away from the base of the system, full of contradictions and different design philosophies. (eg. commctl32, or the new XP theming support). On the whole though, it's a very good system. The reason?

      WndProcs.

      Once you make everything a message, you can do amazing things. Asynchronous programming, for example, is much easier if everything's a message. You also don't get vtable bloat the way you would if it was all implemented as a C++ class hierarchy. Write some templated wrappers (or use ATL or WTL), and you're set to go with the best of both worlds.

      Simon

  • More of an art than science. (Score:3, Interesting)

    by Circuit Breaker ( 114482 ) on Thursday January 10, 2002 @06:44PM (#2820018)
    Operating systems have so much material available because there's science involved - there are a few things that can be proved (e.g., shortest job first, lock-free / wait-free synchronziation primitives, Belady's FIFO anomaly) which should be known to everyone starting to practice. There is also a considerable accumulated body of knowledge which, though not based on solid math, has reached a "common knowledge" status.

    The same cannot be said about windowing systems. The algorithms are well documented, but there isn't much connection between them and actually building a windowing system. Building a windowing system is an art more than science or engineering - a system that's a masterpiece to one is considered bad practice by another.

    That said, if you want to learn from a system IMO exceptionally well balanced between doing things cleanly and making them work, take a look at FLTK [fltk.org] (pronounced FullTick) - it revolves around the ridiculous and totally unaccepted idea that the GUI is only an aspect of your program, and that the logic of the program should not be influenced by how the GUI is implemented. How silly. (Yep, I know, SDNWOTN).

  • No really, I'm serious... (Score:5, Informative)

    by curunir ( 98273 ) on Thursday January 10, 2002 @06:45PM (#2820027) Homepage Journal
    Microsoft's Research [microsoft.com] is pretty good...

    These guys spend a lot of effort answering the kind of questions you're asking.
  • While many argue that Microsoft is a (pardon my french) big bum-bum head, they do have a pretty snazzy windows system (with some exceptions, of course.) You've got to admit -- all security flaws and other massive problems aside, they've been doing windows There's a book that I have found IMMENSELY informative, helpful, and, in its own way, entertaining. It's called Inside Windows 2000, by David Solomon and Mark Russinovich. Mark runs sysinternals.com [sysinternals.com], a very cool site full of windows hacks and utilities that he's written. I run a Win2k network, and the sysinternals utilities have saved my life and a whole lot of work, many times. Check it out!
    • Firstly, I wouldn't call this the "Russinovich book." David Solomon is the first author for a reason: he was the sole author of the previous (4.0) edition [amazon.com] on which Inside Windows 2000 is very largely based. (Helen Custer wrote the first edition [amazon.com] for 3.1.)

      More importantly, this book is just the Windows version of the mostly Unix-centric tomes the poster mentioned he didn't want. A look at the table of contents [microsoft.com] reveals that this book has pretty much nothing to do with developing a windowing system or a window manager.

  • I found this after a few minutes on google. Seems to have a good understanding of the Objectives that UI's produce.

    http://www.sylvantech.com/~talin/projects/ui_des ig n.html

  • I have had the misfortune to have to implement a complete UI toolkit based on the limited capabilities of the JDK 1.1 AWT.

    As far as the high level design is concerned, I can recommend using a model similar to Swing, simplifying where possible. Swing, although implemented horribly, has a fairly clean design and it supports practically anything you'd want from a UI toolkit. Here are some: Model View Controller pattern makes it very modular and therefore easily customizeable, pluggable look and feel which can change at runtime, the event model is clean although sometimes requires you to write a lot of classes just to support a single event.

    Read the swing tutorial [sun.com] or the documentation [sun.com]

  • I would like to have an OS (kernel, apps and everything in between) written in one language and having a consistent and unified design. The language should preferably be some sort of Lisp. I want one language that can serve every purpose, and Lisp is the only language that I know of that is capable of that. Unix systems have all sorts of languages with very different syntaxes used for different purposes. It takes a lot of time to learn everything. Using a higher level language like Lisp would also make the system more secure by preventing buffer overflows and such.

    I would also like to be able to summon some sort of Lisp console from any application. The Script-Fu console in the Gimp is pretty much what I'm thinking about. After learning the language of the system, a person could learn to automate, customize, and extend the functionality of every application.

    • It's called LispOS. Unfortunately, an open source LispOS is quite vaporware. In the meantime, have a look at Squeak Smalltalk , which supports all the features of a modern-day Lisp and then some, with the exception of real macros. Squeak itself is basically an operating system that is hosted by a number of other OSes, including Mac OS 9/X, Windows, Linux, and a bazillion others. In addition to that, Squeak runs bare on a x86.
    • I would like to have an OS (kernel, apps and everything in between) written in one language and having a consistent and unified design. The language should preferably be some sort of Lisp.

      Check out Symbolics [symbolics.com]. They sell the old Lisp Machine software
      ported to a microcoded emulator that runs on DEC/Compaq/nobody Alpha hardware. You can also still find old Lisp Machines for sale occasionally. They're still pretty sweet.

      • I would love to have one of those just to fool around on.

        I would really like to see what a Lisp machine designed today could do. TI used to have a processor designed for Lisp, but the only thing I can find on it is a fifteen year old press release about it.

        Of course, it's incredibly unlikely that any company would design and market a new Lisp machine. Lisp has fallen out of favor and everyone cowers in fear of anything that breaks compatibility with what they already have. I wish everyone could agree to throw out all of our current hardware and software and make a fresh start. But only silly, impractical people like me would like that.

    • I would like to have an OS (kernel, apps and everything in between) written in one language and having a consistent and unified design. The language should preferably be some sort of Lisp. I want one language that can serve every purpose, and Lisp is the only language that I know of that is capable of that. Unix systems have all sorts of languages with very different syntaxes used for different purposes. It takes a lot of time to learn everything. Using a higher level language like Lisp would also make the system more secure by preventing buffer overflows and such.

      This is what Emacs will become in a couple of versions.

    • I'm with you, man. Unix and Windows have proven that C is not suitable for a networked system that needs security.

      Squeak is pretty cool, but I like Lisp dialects better than Smalltalk.

      The problem is the lack of a Lisp dialect compiler suitable for OS-level work as illustrated here [sonic.net].

  • auto GUI?? (Score:2, Informative)

    by Hooya ( 518216 )
    i've been thinking about this for a while and i'm not sure if it fits the bill for your question about windowing systems but here it goes anyways...

    after working nmap and then with nmapfe, i had the idea where you would write your tool as a native CLI base program but one which provided hooks for a gui over it. nmapfe simply, as far as i can understand, does this by using the GUI to construct the command and then when hit 'enter' running a system call. this approach could be further extended by providing some hooks into the native CLI program whereby a generic GUI tool could probe the tool to see what screens to present to the user.

    for example, in the document-view setting, have the view class just generate some form of xml (glade-ish) so that this generic-runtime-gui-builder can query this command line too to build the gui for it. this is all so that each and every tool would have a commandline and a GUI in a very consistant fashion. also, most of the time, the huge GUI programs are just replicating the code for the GUI. this all could be in one generic GUI-runtime-builder.

    i know this is all convoluted. i'm still trying to work it out in my head.

    i did go as far as creating a 'browser' where you'd run this generic-window which then pulled the interface requested by the app into the main window using glade. just that bit is quite simple. but i'm still working on the rest of it...

  • It's a ten line program (Score:5, Funny)

    by CatherineCornelius ( 543166 ) <tonysidaway@gmail.com> on Thursday January 10, 2002 @06:55PM (#2820091) Journal
    #include <rants/usability.h>
    #include <rants/msvapple.h>
    #include <rants/nextstep.h>
    #include <slashdot/troll.h>
    #include <stdio.h>
    int main (int argc, char *argv[])
    {
    puts("Real programmers use curses");
    return 0;
    }
  • If you know classes and the virtual command, then simply make the windows as classes, and the small pieces in them as subclasses.

    I made an awesome AWT in about 2 months for my MMORPG using C++. Too bad the market got swamped.

  • SVG GUI (Score:3, Informative)

    by schepers ( 462428 ) on Thursday January 10, 2002 @06:56PM (#2820098)
    There is a new SourceForge [sourceforge.net] project called SVgUI [sourceforge.net]. The intent is to make a windowing system--Web and possibly desktop-based--using Scalable Vector Graphics (SVG) [protocol7.com]. There are no released files yet, but several promising examples of GUI elements have been posted on the SVG-Developers list [yahoo.com].

    Sorta off-topic, I know, but you might be interested in working with a community from the ground up.

  • What level are you trying to address (Score:4, Insightful)

    by ReelOddeeo ( 115880 ) on Thursday January 10, 2002 @07:04PM (#2820152)
    I see (at least) 3 distinct levels, and I'm not sure which one your question addresses.

    1. Low level graphics manipulation. I would put X here, although X includes network transparency. What I see at this level is graphics primitives. How to draw a circle, a line, a rectangle, draw characters of text in a certian font, etc.

    2. A window manager / widget toolkit. There are already five million of these for Linux. They can be fun to write and educational. But don't have any delusions of gaining significant market/mind share.

    3. Human-Computer interaction. User Interface. This is more about human psychology than it is about technology. Read some good books like The Design Of Everyday Things. Apple Human Interface Guidelines. (Apple's developer web site.)

    Your question makes fairly clear you aren't interested in (1). But it is ambiguous whether you are interested in (2) or (3). If you're interested in (3), then join either the GNOME or KDE projects and contribute ideas and effort that don't involve writing code.

  • Understand prior art first (Score:4, Informative)

    by Havoc Pennington ( 87913 ) on Thursday January 10, 2002 @07:23PM (#2820280)

    Here is the classic paper on how X could be improved, for example: http://www.std.org/~msm/common/WhyX.pdf [std.org].

    Write a window manager and fix some GUI toolkit bugs, that's a good way to understand X well. Hack on GUIs like GNOME and KDE to understand where progress is needed on the UI front, and where changing the window system could help.

    (I think almost everyone who's actually hacked on this stuff a lot will tell you that replacing X isn't interesting, but if you want to make a credible claim one way or the other, getting experience is the only way.)

  • Plan9 (Score:5, Interesting)

    by horster ( 516139 ) on Thursday January 10, 2002 @07:25PM (#2820296)
    go to the plan9 site -
    http://www.cs.bell-labs.com/plan9dist/
    (for starters see this paper on the old plan9 window system) - http://www.cs.bell-labs.com/sys/doc/8%bd/8%bd.html

    there is some information there, and the source code for the window system is actually readable because it is much few lines of code and over all simpler than x windows.

    also Rob Pike (who worked on plan9) has written several interesting papers on windowing systems.
    try reading them by poking around this site - http://citeseer.nj.nec.com/144447.html
    http://citeseer.nj.nec.com/pike89concurrent.html
    (sorry the actual articles - linked off of the above links are only ps or pdf, no html)

    These papers, the plan9 window system as well as the inferno window system prove that a simple, elegant window system can be created that is both fast and runs over a network.

    Granted these use some features that don't exist in the unix world (like plan9's threading model, and the use of per process namespaces) but I believe these can be emulated somewhat using standard networking.
    The size, complexity and performance of x windows are all indications that it is not the optimal solution.
    • Pike gave a talk at some Usenix a decade or so ago(I think Nashville?) on Plan 9's window system named 8 1/2, and on his "acme" user interface on it. One remark I remember was that "Ken Thompson and I spent a decade learning about things that window systems shouldn't do, and wrote one that doesn't do them." It's extremely lean and mean - I think he said the source code was about 64KB (could have been 64K lines?) and compiles in ten seconds on the Plan 9 CPU cluster (which was a then-blazingly-fast multiprocessor SGI, probably a couple hundred bogomips.) What impressed me was watching him start the window system from a shell prompt - he typed "81/2", hit return, and in about the time I'd have expected to get a $ prompt back, there was a running windowsystem on the screen - certainly under a second on a NeXt 680x0 box.

      Yes, if I had real Unicode I could have written the "1/2" as a single character like Pike does

  • No more, please!!! (Score:3, Interesting)

    by suso ( 153703 ) on Thursday January 10, 2002 @07:34PM (#2820347) Journal
    PLEASE PLEASE PLEASE PLEASE PLEASE!!!!!
    Don't write any more window managers or windowing systems. When there are window managers out there called "Yet another window manager" or "Yet another window manager2" along with all those window managers that aim to be something special. It's just got to stop. What's needed are better applications that you can be productive with. Please focus on the applications that people demand, not on the ones that you think would be cool to write.
    • there are window managers out there called "Yet another window manager" or "Yet another window manager2" ... It's just got to stop.
      Should people quit writing parser generators [compilertools.net] and Internet portals [google.com], too? :)

    • Re:No more, please!!! (Score:2, Insightful)

      by Kidbro ( 80868 )
      I agree!

      You should spend your free time doing what I want you to do because I'm to lazy to do it myself, rather than what you think would be interesting and fun to do yourself.

      duh :)

      Anyway, irony excluded, the guy is speaking about a windowing system (think X) rather than a window manager (think fvvm). Don't confuse the two...

  • MVC and Views (Score:4, Insightful)

    by KidSock ( 150684 ) on Thursday January 10, 2002 @08:10PM (#2820549)
    The foundation of all windowing systems is the Model View Controller mechanism. There are surprisingly few good examples of source code or descriptions of how to actually implement such frameworks but the general idea is well know and easy to understand and appreciate.

    The Model View Controller framework abstracts the three separate components of a basic user interface. The Model is the data. This might be a double subscripted array of numbers or a tree of arbitrarily complex nodes. The Controller is probably a keyboard and mouse. There would be some driver code that would deliver mouse and keyboard events to the object currently in focus (or to what ever object registered itself as an event listener). The most important and more sophisticated of these three components is the View.

    The View is an area (usually rectangular) of the display device such as a monitor or printer. The key principle behind a view is that it's potentially the child of a parent View. Thus each view may contain subviews each with their own coordinate space. Within a view graphics primiatives and subviews are drawn to create arbitarily complex grapical interfaces. Because the translation to display device coordinates is handled by the graphics context passed to all drawing functions (Graphics g in Java AWT), the implementation of a subview may draw it's widget with respect to coordinates 0,0. This makes it very easy to integrate new custom widgets (widgets stands for "Window Gadgets"). So, for example a frame is a View with a border, a label, and maybe a scrollbar. It has two buttons, some text, and another frame as children. The button is a View that contains a border decor and some text ... etc. This follows the process of Recursive Composition. There is a good description of Views in the BEOS documentation which unfortunately I cannot link to because BE has apprently disabled much of their site. I would appricitate it if someone could point me to a valid link to the description of the BView class.

    Ironnically, this framework is repeated in software over and over where only one would really be necessary provided the API were general and flexible. For example, the X-Window system is an MVC framework. But Mozilla has it's own MVC framework for drawing GUI components. Then within Mozilla's rendering engine Gecko is another MVC framework for rendering html components.

    In this last case of Gecko, I can understand why they would not want to use a generic windowing MVC API; the layout of components is very strict in that images, links, and the way text flows around components is required to behave in a certain way as to conform to the various associated standards such as CSS and DOM etc. It would be interesting and simplify things tremendously if one could reduce and refactor one unified implementation that parameterized all the different requirements of these MVC frameworks. Then custom components could be potentially integrated into previous unrelated applications (e.g. vi in xterm as the text area of an HTML page).

  • Check out the Cassoway constraint engine's port to the Squeak system if you are serious about doing new UI/layout libraries: http://penguin.cc.gt.atl.ga.us:8080/schwa/63 For those too lazy to install Squeak and run the above constraint change set for Cassoway under it, here's a little Java 1.1 applet (better run it on Nav4.7x or above) demonstrating how the Cassoway engine maintains dynamic UI consistency within constraints (better read the instructions): http://www.cs.washington.edu/research/constraints/ cda/run.html
  • It seems to me that a lot of other people have had similar ideas, and the results have all been built on top of X. GTK/Gnome and KDE being two popular examples. I admit that my understanding of what X Windows does is fairly limited, but as far as I know it just a very fast, well written program that draws shapes on your screen and coordinates mouse and keyboard input, all rolled up into a tight, clean client-server interface. I'm not even all that sure if X Windows knows about actual windows; I believe (and this is insightful) that that's handled by the "window manager." So I think when you talk about rewriting the interface, don't you really want to think more about building your own windowing environment on top of X?

  • Implement on top of OpenGL (Score:3, Interesting)

    by Animats ( 122034 ) on Friday January 11, 2002 @03:29AM (#2822086) Homepage
    If you want to do a new window system, try one on top of OpenGL.
    • You can run on top of Linux, Microsoft, and Apple OSs, plus some others.
    • There's a well-defined API for talking to the display system.
    • By the time you get it done, everything on the market will have at least NVidia NForce 3D acceleration (which is equivalent to a GEForce 2), if not better. So there won't be a performance problem.
    • You can double-buffer, so that users never see partially drawn windows.
    • You can scale and morph windows easily, so you can implement effects like MacOS X, if you want to.
    • You can port Quake to it.

  • People here seem to forget one thing: There is a framebuffer support in Linux kernel. I know it's still experimental (my experience is that it's quite stable ayway) but..

    If you want to do windowing system, want to support a lot of hardware with at least on basic level (VESA) and think it's OK doing it on Linux, try compiling the framebuffer support into your kernel (if it's not there already) and building your system on top of it. There some points why this would be a god idea..

    • You don't have to care about the low-level stuff
    • You are in less risk of having to reboot as you are running on one virtual terminal
    • Now (slow) mode switches when you change virtual terminals -> easier to do debugging
    • Anybody with framebuffer-support will be able to join the development as it won't be one chipset/graphics card only..

    If you make it modular enough (nice wrappers for all framebuffer stuff) it will be easy to port it over to something else or build real hardware drivers later. This way you can first get something running and only then see if you/or somebody can make a better driver for it

    Who knows if the project would even speed up framebuffer development if it gets popular enough :)

  • QTopia...? (Score:2, Interesting)

    by abdulla ( 523920 )
    i think QTopia is a great idea, if only it ran on desktops
  • It's called "X11". X11 isn't really a "window system", it's a network transparent graphics library. X11 gives you the low-level graphics, access to hardware acceleration, and network transparency. You can build whatever "window system" (in the Windows/Apple sense) on top of that: your own APIs, your own window management, your own input methods, etc.

Slashdot Top Deals

"Experience has proved that some people indeed know everything." -- Russell Baker

Close