Xlib-based code can't be faster than toolkit-based code, unless the former has inefficiencies; this is obvious because the tookits themselves are Xlib-based. (Well, unless the toolkit is written in a more efficient language than the implementation; since Xlib is a C binding, this is unlikely to be the case, especially here.) There is some force to the wheel-reinvention argument, but it's also often the case that the wheels provided by the toolkit are a bad match to the application (to varying degrees), so it's a question of whether it's better to build a wheel that does just what the application wants or to use a preexisting wheel that doesn't quite. Without knowing more about the specifics of this case, I couldn't offer an opinion on which this is. Also, the toolkits often are themselves pretty horrible code; I recall the shudders that came over me, years ago, when I looked at the Xt API and saw that it depended on casting from a pointer to an integer and back to preserve the pointer (or was it the other way around, integer to pointer and back? I forget). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Brian L. Stuart wrote: It's already been done, and now there are standard wheels (GTK, QT, etc.). Using an existing system allows your application to function well, and allows you to think about more important things than "Gee, this thing would look better if I moved it 3 pixels to the left and changed the color a bit. Oh well, I'll have edit the code some more because I didn't make a facility to do that." Then, you have the disadvantage (some would say advantage, but I'd say that's misguided) of having your app look and behave completely different from everything else the end user runs. These days, end users expect well behaved applications that are similar in their interfaces. Besides that, there's a huge added bonus to using wheels that already exist, if you use the right kind, your app suddenly can run on OS X, Linux, *BSD, and, yes, even windows (assuming the rest of it is portable enough). Yes, it's perfectly fine to reinvent the wheel if you're in the business of making wheels. But if you're making cars, it's in your best interest to use standard wheels.

Brian L. Stuart wrote: Yes, but the car analogy isn't going to be perfect. :) Nothing wrong with that. If you want to be in the business of making wheels, by all means. Reinvent away and build your own toolkit, and stick to whatever standards you need to stick to (or invent your own). If you're in the business of requiring wheels for a particular task, by all means use pre-built wheels. I hardly think building emulators is bread and butter programming. :-) But, building a UI from scratch in Xlib is a completely different task than building an emulator and making use of pre-build toolkits. There is at least an order of magnitude worth of difference between rolling your own from scratch and using a toolkit. So which business are you in? Making emulators? Making tookits from scratch, or both? If you're in both, hey, that's wonderful. But if you're just interested in making emulators, then building an entire toolkit seems a waste of time - sure there are reasons for it (you like the challenge, or you want to reuse it elsewhere, etc.) but if you don't meet those reasons, you're just wasting cycles better spent making the core of the emulator better. And there is a ton of stuff to do when rolling your own. You need preferences, file pickers, dialog boxes, windows, keyboard interfaces, etc. It's a huge undertaking. And in the end your application will be locked into to a single platform (or sets of platforms), will look and behave like nothing else (which annoys your users), and won't benefit desktop these days has certain preference settings that users can set as to color, look and feel, etc. Agreed. There's also using the right tool for the job too. Nothing wrong with building your own tools, and for that matter, your own screws. But if you go the route of making your own screws, they won't fit anyone else's. What would you gain exactly over say a flat, phillips, or torx? (I say screws because that's a problem Babbage had - no shop built screws quite the same way, so he had to pay a lot and spend a lot of time to get exactly the parts he needed.) It's more than that, the implication is don't reinvent the wheel unless you have a specific justifiable need to do so. And who knows there are those who might. But for 99.99% of things, it's just a waste of time.

der Mouse wrote: Bah, write your own wrapper that you can stand - what's a little extra bloat these days? Just throw more hardware it it if it's too slow... ;)

Gordon JC Pearce MM3YEQ wrote: Seconded. Go with something like wxWidgets or QT-4. I wasted many months reinventing the wheel, yes it's cool to write stuff raw in xlib, but it is a huge waste of time in the end. I had to rip out all that junk and redo it properly, and I don't regret that at all. Grab the wxWidgets book and go to town, you'll never look back.

cq Xlib vs. the various Widget toolboxes My GUI needs were very limited : This is the main reason I could get away not using a toolkit. check on ftp://jdreesen.dyndns.org/ftp for some screenshots of the emulator. Codesize for the GUI section is around 100 lines of C, time to implemement probably less than would be needed to master a widget set. And yes, I liked the idea of trying to limit myself to Xlib. Anyhow the interesting part should be the Lilith emulation itself, and writing documentation and preparing diskimages will be enough work. But, yes, if I ever port this to C++ I will go for WxWidgets. Jos

Jos Dreesen / Marian Capel wrote: I'm not familiar with the Lilith, but won't you have the ability to change features? Insert disks or tapes? You might find it's a pain to build a file picker in Xlib. As an example. Dialog boxes for "Ooops, the emulator died." or "are you sure you want to destroy what you were working on", and so forth. Exactly. Not trying to push wx on you, you might be able to do plain old C in QT or GTK (not sure, I don't know those). If you do go with wx, you don't need the whole thing in C++, just the UI pieces. Anyway, that's very cool to see another emulator. :-)

der Mouse wrote: Well, UI design, is a long and huge topic. The toolkit doesn't generally enforce policy on UI design, typically, the vendor provides a best practices spec. For example, back in the day, Apple had a very nice little Hypercard tutorial called "Making it Macintosh" that showed what they thought was the proper way to do things. These things can be quite useful. For example they describe under which conditions to use a list, radio boxes, etc. In terms of what you want in an emulator, it all depends on how you virtualize access to the hardware. You need some way to tell the emulator what file to use as a virtual hard drive, where to direct serial ports, how to deal with networking, etc. Each of these can fail in their own way, and differently from the way the original hardware would, so you need some way to interact with the end user. And that's where the problem lies. Not all users are a like. Some want as little UI as possible, others want more. Some want a text log, others want to be notified. So it's hard to balance things out. Ideally, and this is a personal view, I'd like to be able to show the user what the hardware looked like and let them drag and drop cables or click on buttons. Granted, it's not the same as on the real hardware, but it's a step closer than just providing display output and not much else. I've avoided adding too many normal UI items in LisaEm, and stuck with using the menus as much as possible as they're less intrusive. But there are times when you need to be able to tell the user, "Hey this disk here has a serial number, deserialize it?" - and I've found that in the long run that kind of pop up dialog box when you've just seen a file picker is annoying. So yeah, in the current version (not yet released), that's been replaced with a menu command that deserializes disks. I don't know if that's a better approach, but personally it's less annoying. For other things, if the user runs without a ROM, I let them pick what device to boot off. Sure, I could have written my own ROM or taken screen shots of what it looks like with the ROM, but wanted to make it clear when they're running with or without a ROM, so instead, I presented a normal list picker, so it's clear they're interacting with the emulator and not the Lisa ROM or the OS. Was this a good decision, I don't know, but I'm comfortable with it and so far no one's complained. Now when you run without a ROM and your OS can't boot (maybe because you've tried to boot off a non-bootable device, etc.) I put up a dialog box saying that it failed and put up the error code the OS returned. Additionally, I keep a list of text descriptions for the failures and say those as well. You don't get that when you run with the ROM, but IMHO, it's helpful to know why something failed (so that as a programmer, I can be alerted to why it failed, not so much for the end user, although they benefit too.) So, in this case, a pop up dialog box is useful. Others have opted for a status display, maybe in the form of a bar, or button bar or a status line or whatever. I have some of this too, but I want to keep from being intrusive and I don't want this to be the UI that controls the operation of the emulator. Rather, I want the user to click on the floppy drive when inserting a disk - for example. Sure, there are a lot of analogs you can't provide for that way, and there are a lot of places inside LisaEm where I'd like to provide more real-life like configs. But I am very much interested in the process of making those decisions. Why use wxWidgets vs Qt vs GTK vs pure Xlib. Why implement is menu items vs a button bar, vs simulating what it looks like in real life. How to interact with the user, how to configure things, etc. Some of those decisions are personal, others are experiments, but most are "what do other apps which don't annoy their users do?" (and not necessarily other emulators.)