Project X: About the Developer

Project X: About the Developer

These are some of the questions I answered online at "The BeOS Journal"

Can you describe what you mean by 'unusual' design interfaces?

The unusual GUI design interfaces involve using the best of both worlds of the GUI portion with a command line interface: both are integrated in function, and everything is possible (short of needing to type text to create something) without requiring a mouse to get there; the GUI is designed for the fastest keyboard navigation possible, with great care paid to tab order. The underlying design is meant to be maximally functional with minimal user distraction, with all visual detail created for showing useful information, with minimal functionless eye candy. The GUI design of “Project X” will (as far as I can do it) allow anyone with any level of vision to use it in a productive manner; as many as 1 in 12 people have color perception abnormalities (I don’t personally, but I’ve worked with many that do), and many more people than that have other visual perception problems. Thus, I’m designing the GUI to be functional in black and white, as much as possible, such that color is just an added way to communicate the same information. Usability and efficiency as well as stability are the design goals. The user interface will be as orthogonal as I can figure out how to make it, which will also result in less code writing and debugging for me.

Do IDE environments today not work as well as you want?

Take Visual Studio, for example: it’s a very powerful IDE, but the power is often inefficient to use due to the complexity of the interface. You need to remember either a very large number of keyboard shortcuts, or you are stuck using a mouse. When it comes to creating new variables, derived classes, methods, etc. in the class wizard, you have to navigate a rather complex dialog and you are stuck working within that dialog until you’re done, with no way of looking at something you might be interested in for a reference. If nothing else, the dialog box obscures your vision of what you’re working on, and having to enter a complicated dialog box as done by typical IDEs involves a major distraction, even if things work right.

Also, with all the IDEs I’ve seen, all generated code is inserted in an order forced by the IDE, with no way of changing it, short of editing it by hand; this defeats the point of using the code generator in the first place, since you’d hope it would make things more efficient.

Can you elaborate more on your computer background?

I’m one of those people that reads OS source code for entertainment purposes J I have over 20 years of experience, starting with TRS-80’s with cassette tapes, and learned 6502 machine/assembly language on the Apple 2 series, and I earned my high school varsity letter via the computer club programming competitions using Apple ][e’s with AppleSoft BASIC in a format that resembles extreme programming as seen today. I assisted a friend down the street that wrote Apple 2 software on writing a ProDOS disk defragmenter in the late 80’s, when people were just starting to have hard drives for their computers. I wish Apple had continued with the development of the Apple 2 series, as there was plenty of room for the processor family to grow, and the Apple 2GS was way ahead of its time in both the power of the OS for the hardware it ran on, along with the hardware itself. The 65C816 was the closest thing you’ll find to a RISC processor with 23 addressing modes, though some of them were purely optimizations for dealing with 8 bit limits. However, it could work with more than 64K data with instructions without going into segmentation like the Intel processors, and could address 16 megs without a problem. Do I sound wistful about those times?

Other than that, my professional experience has been writing software for mission critical applications, in terms of the fact that time and reliability of the process were not merely important, but vital. This includes low-level experience writing for SCSI devices such as CD-ROM drives, tape drive and CD-writers for CD-ROM pre-mastering utilities working for Digital Audio Disc Corporation, as well as being part of the team that created the first mastering machine solution to creating production multiple session discs (Surely people have at least one of those in their collections, the ones where an audio player only sees the first track(s) as audio, and doesn’t see other sessions, thus avoiding listening to application code). I also wrote an application to analyze CD’s at a very low level for adherence to standards that first started out in Windows with heavy C++ object oriented design, and then (at the demand of the project leader) found myself having to port it to ANSI C under Linux using a multiple process design instead; thus, I have some rather interesting experience with knowing what a C++ compiler does for you and to you! The next employer had me writing software for an engine monitoring system, collecting and analyzing telemetry. My most recent employment involved writing software for controlling CNC milling machines and press brakes that aren’t shut down unless they break or need repairs, and the software was designed to be that boringly reliable. I’ve been writing software in C/C++ since 1992, and have collected a lot of arrows in my back, used several different OS’s and development environments and APIs, and worked both in teams as well as individually.

Are you interested in help from other developers if anyone stepped forward? Have you had any offers already?

I’ve had offers for beta testers to help me already, but I’m not ready for that yet anyway. I’ve had more questions of why I haven’t helped on other existing projects. Other than having beta testers verify “Project X” works as desired (I’m confident it will be very stable, but everyone has their own idea how things should work, and anything this complex will have at least minor bugs before release, as well as likely after) I have no real desire to have others help me with the code itself, though there might be questions I might ask about doing a few things here and there. I have a clear vision of what I want to do and why I want to do it, based on personal experience and a certain amount of market research over time on BeShare, where I’ve previously logged in as coolbear; coolbear is an ancestral name I’ve used because it’s a lot more likely to have fewer name collisions on the web than my legal name. For those that have suggested features in the distant past on BeShare, be assured, I have not forgotten them!

How fleshed out is your design now?

I’ve got about 30 typed pages of description of the structure of how it should work and look, as well as the threading model that goes along with it. I’ve had this on my mind for over 3 years now, and I’ve waited more than patiently for other projects to get complete enough to fill my needs, but I could wait forever if I don’t do it myself. The BeOS GUI API with the requirement of having a thread for every window and the application itself makes it a non-trivial task for ensuring that things don’t get created and destroyed in such a way that avoids deadlocks and crashes due to invalid pointers. However, I have a solution that guarantees windows are not created or destroyed unexpectedly, and the manner of controlling them ensures no deadlocks as a result. Hopefully, this won’t be regarded as rocket science to everyone, but just good common sense. I anticipate releasing a minimal weight document/view library with “Project X” that demonstrates by real code how that works, and I think it will help quite a bit.

Will 'project X' be compartmentalized enough to allow several small tools to be spun off separately as downloads on BeBits?

Yes, due to how I design and implement software, it defines “modular” by example.

Are you planning to go fully commercial after enough development, or will it be open source all the way? ;)

“Project X” is not going to be open sourced, and will be a fully commercial product with no restrictions on people reselling/redistributing their applications that link to any libraries I might distribute with it. I haven’t completely decided what license to use for any external libraries I create, but it will NOT be GPL, as that’s too restrictive for anyone that wants to sell their applications commercially.

Are collaborative features on the todo list? ie; More than one coder working (remotely) on the same project/source file?

Yes, though not as a 1.0 release item. It may be a non-version add-on later on (TBD), but the IDE design takes the thought of multiple things going on simultaneously into the threading design and data structures. I see no practical reason why people couldn’t watch what others are typing as they type it, and excluding the compilation of certain source files until certain conditions have been reached. It isn’t rocket science!

And finally, if you had to give advice to people new to BeOS, what would it be?

That’s a two-pronged question in terms of how I would give advice: I have to break it down for developers as well as end users that don’t develop. That’s because end users often don’t see everything from the same viewpoint and understanding of developers, and developers are often just as blind to the other side of the coin, and everyone ends up on edge.

To new users that don’t develop, please, support the developers by buying software for sale that you think you’ll need or want, but in relation to part of my personal philosophy, do not tell beautiful lies to others or the developers in relation to software; tell the truth, though try to do it as tactfully as possible, to minimize hurt feelings. As an example, don’t go around telling everyone, “Oh, this software is so great! I can do this and this and this, and it’s just plain neat!” when in fact the software in question has major stability and usability flaws that render it far from useful. Software that isn’t reliable is a liability, and promoting something that’s truly horrible as being great only damages everyone: other potential users and the community at large, as well as the developer of that software. It damages the community and other potential users at large because they are working in delusion, and place faith where it’s unwarranted, and will soon lose faith in anything related to the community and the OS and the software and its developer. This is especially vital for software that costs money: who has bought software in the hopes it was stable, only to find they wasted time and money? Please, don’t keep buying shoddy software that doesn’t fit your needs, and especially don’t buy software just for the sake of supporting a developer, if you honestly know you won’t even use it. I even suggest that to those that may wish to support me in my development and continuation of Project X: I’d rather have a customer that appreciates my work for satisfying their own requirements, rather than get money as a pity purchase. If you have discovered (as a user) that you can work around the problems in the software, when you promote the software, please, explain that there’s this open manhole cover you should watch out for, and give a path around it. However, please don’t stop there when you run into such a thing: do your best to decipher the simplest conditions are required to cause that software to fail, and give a detailed report to the software developer via email or the preferred method of communication (BeShare, website, etc.) along with the system configuration. Developers are human, and don’t always account for all possible choices a user can make; in addition, developers are on a spectrum from beginners with no real experience, to those that are accustomed to writing mission critical applications. Stroking the ego of a developer by leaving out vital details like reproducible flaws is FAR from being beneficial, because it creates a false sense of security in their accomplishments; they think they’ve produced the eighth wonder of the world, and wonder why the world doesn’t even pay it an eighth of the attention they feel it deserves, not comprehending that it doesn’t work properly for the ones they would develop for.

To new developers, there are many things I strongly suggest, and they don’t apply only to BeOS:

1. Learn the language(s) of choice you wish to develop in.

2. Find a need and fill it, getting feedback from potential customers before you release, to know that you are solving the right problem.

3. Learn the system limitations and how it affects your application and the users of your application. Without users, you have no reason to develop software.

4. Remember to respect users as your customers or your boss, regardless of whether you charge for your software or not. Everything else comes down to professionalism and respecting the customer.

5. Make yourself accessible to users for support and feature updates, as much as possible. At least provide a way for them to submit suggestions and report bugs; try to release bug fixes (tested, of course!) as soon as possible. These things are much more important for commercial software, as customers expect to get more service for their money than for software that is free and/or open to their modification.

6. Write proper documentation for all of your software features, as well as making the software inherently easy to use, where that depends on the nature of the application. Remember, try to make it easy for the user to use your software as you intend, but don’t make it so Byzantine that they find themselves wondering how to accomplish something. Hidden, undocumented features are at least as likely to be reported as bugs when a user discovers them, so you actually may save yourself a lot of hassle if you document how and why your software works in a given manner.

7. Test your software to the limits of your system, then make a way for others to torture your software on their systems. The multithreaded nature of BeOS and GUI apps for BeOS make this even more important, in that testing is made much more difficult. Test your code on uni-processor as well as SMP machines, and test on as many speed variations as possible. Properly written and designed applications will work correctly on every system and every speed, regardless of how slow or fast the machines or the application is. Of course, if the machine isn’t fast enough to do something like render live video, there are practical limits. Nonetheless, it’s good to know what it can and can’t do. Test your software in as small of parts as possible, before you integrate it into the larger whole. This takes more effort than testing the application all at once to setup, but it’s worth it.

8. Do a test install of your software on a cleanly installed partition. The development machine is tainted, and will provide false results if you’re missing something in the installation steps.

9. Design for usability in many ways: localization, font sensitivity, appropriate icons, etc. as well as color schemes. Weigh carefully any new GUI controls you may create for a GUI application. If you are doing something new, if it varies too much from what the user has previously experienced, you’d better document how it works, and explain why it’s better. Don’t use assumptions about the system font size and language, or colors. Don’t assume that your users have full color perception. Don’t assume that graphic icons alone will convey the right meaning. Display the application status accurately, visibly disabling features that are not valid during the current state. Give meaningful error messages when something goes wrong (desirable), and try to ensure that the user can’t choose to do something that can create an error message in the first place (better, but not always achievable).

10. Buy the book “Large-Scale C++ Software Design” by John Lakos. While it shows examples in C++, the principles covered in there apply as well to any language when it comes to things such as cyclic dependencies. In fact, cyclic dependencies are far more fatal with a multithreaded application as any GUI app in BeOS will be: cyclic code is more likely to cause deadlocks and crash conditions. There are many reasons I mentioned above why this book is important to understand and use in practice.

11. Ensure that the user doesn’t lose data by some flaw.

Remember that you only have one chance to make a first impression: if an application crashes or locks up before they can even see what else it might be able to do, you stand little chance of winning them over, unless the user is very patient and forgiving.

Visits: