laststep

Just a very brief update on my project. Right now I’m working on Milestone Build 1A115, which is the first one to provide a graphical login service. From there you can click on your user, enter password, and you’re in – the usual. As with most systems out there, even on Mac, LoginWindow.app can never ever terminate. If that happens, well, your desktop and everything in it and on it crashes with the service.

That way my Desktop can connect to the login manager and give the instruction to log the user out. LoginWindow.app therefore effectively links the most vital components – which is why 1A115 is a milestone build. As some developers might want to develop widgets (Cosmoids) that allow you to log out with one click, the API to connect to LoginWindow is obviously open to anyone to implement.

In case you were wondering about my versioning… First is the version of the system, in this case 1. The letter that follows describes what it is. A = Alpha – B = Beta – F = Final. A in this case. The last digits are a steadily increasing number. The higher the version, the more improved the code is.

It’s pretty much complete. For the moment it does not log you in – that may be because I haven’t implemented the final touches yet =D

Nonetheless, I think this looks pretty good:

I am still working on the boot up routine which should include a graphical boot. However after doing some modifications to the start up scripts, a graphical boot seems no longer necessary and I can directly go into graphical login. As of right now I didn’t write the login application yet, but this is up next.

As the title says. I am working on a graphical boot implementation which starts right into X11 while the system is loaded. While the system is booting one should know how long it is going to take until the computer is usable. Once everything is done, and since we would already be graphical, I only need to switch to the login manager.

So I am working on some ideas… here’s one mockup I made (meaning not a real screenshot! And yes the progressbar is from a Mac, I just change the colors. A Aqua progress bar will obviously not be in my project).

I think a progress bar at boot is good, the user knows how long it will take until he can log in. In my opinion, a simple logo is, well, just too simple.

If you have any improvement or other ideas, please let me know.

Boot Mockup Screen Idea 1.

Nice one. I should consider this for my laststep project.

My project has progressed to a point where I can no longer use a virtual machine for development, the way I used to do it up until now. Because Voyager, the file browser, requires hardware support, I now have to use a real world machine to test things on. Wait what? A file browser requires hardware? Well you know if you want to browse through your USB drive or music player, you need it =) This is the reason why I moved to a real world machine.

Since I want laststep to be a rather unique platform, the base underneath is substantially different from other Linux/Unix-alikes out there – but maintains the established folder hierarchy standard, so everyone can operate safely in both eras.

Newton is what I call the base of laststep, the foundation on which everything is going to be running on. The biggest difference with Newton is the folder hierarchy, which is outlined below. As a filesystem, laststep is going to use JFS by default.

/		File system root inside which everything else resides in.

/Applications	The default location for all GUI applications
| /Utilities	Command-line or GUI tools of administrative nature

/Library	Contains all libraries and corresponding files

/Network	Network drives and other related files

/Private	Holds tools and configuration files, private to the OS,
		contains /bin, /etc and so on.

/System		Everything vital to the system
| /CoreServices Crucial services such as the Desktop, Grids, Rewind, etc
| /Kernel	Kernel and all related files
| /Library	Internal libraries and other system-crucial files

/Users		Contains all data and files of a user's account

/Volumes	Directory inside which removable medias will be mounted,
		like USB drives, DVD's, digital cameras...

However the standard directories like /etc, /usr, and so on, are still accessible and can be changed into. For example if you do
cd /usr/bin
it will work, but in reality you are in /Private/usr/bin.

The only remaining entries in the root tree are /dev, /proc, and /sys, as these are virtual file systems required by the kernel to be on the root folder.

You know I could have gone and write a simple file manager. But by the scope of this project, a file browser has to be a bit more than that. For my project, I call it Voyager. It doesn’t look like much right now, but so far it required some work.

For example one file browser window can have many instances of the file browser itself, by using tabs. The Explorer in Windows 7 does not have tabs, neither does Mac’s Finder. I kinda like tabs so I built them. So that was the first element required. This view is also available to developers for all kinds of things. LSTabbedElementView is the class name for it.

Next thing up was the creation of a preliminary version of the background indexing service, which should be known as Searchlight. It is using SQLite and stores all information in a central location. Information stored is vital basic data such as file name, location, among other things. On top of that you can store a description for a file/folder, as well as meta tags. Music files have special fields like artist, composer, album, etc, while photos have geo-tagging fields. Also, a file can be flagged as a favorite – and thus the machine knows what things you prefer. Ultimately you can search for practically any conceivable criteria or combination of criterias, in one or many locations.

With those things implemented, it was possible to create a preliminary interface for the browser, looking like this:

Click to enlarge

As you might have gathered, I pick up on speed with my little project. Now that many components are written and in place, I can pretty much add anything I want, really.

The next thing I decided to add after virtual desktops is a little widget engine that allows you to add little bits of information on the desktop, like you would expect it nowadays from a modern operating system. The widgets can have any shape and form, can even be completely translucent.

To make this possible I had to create a parser for the files that contain the information for the widgets… sorry, Cosmoids. Those are CML files, and are in a very simple format, I explain in a second.

Seeing is believing eh?

This is the little testing and demo Cosmoid. As you can see it has a text label, an image, and two buttons. When you click the “Rain!” button, the image changes. No wai!!

Nothing spectacular, but it demonstrates that it works.

This is the corresponding cosmoid.cml file which is read in the beginning and makes up this particular Cosmoid. First entirely:

[Information]
Name = Demo Cosmoid
Background = Resources/csm_back.png
Active = YES

[Dimensions]
Width = 300
Height = 200
Position = 827.000000, 764.000000

[Content]
TextLabel = helloLabel, Hello Cosmos!, 250, 20, 25, 150, white, bold, 16
Image = sunImage, Resources/sunny.png, 90, 20
Button = sunChanger, Sun!, sunImage, setMyImage:, Resources/sunny.png, 100, 20
Button = rainChanger, Rain!, sunImage, setMyImage:, Resources/rainy.png, 200, 20

That’s it! Isn’t that simple? Let me explain some things.

[Information]
Name = Demo Cosmoid
Background = Resources/csm_back.png
Active = YES

This block should be obvious.

[Dimensions]
Width = 300
Height = 200
Position = 827.000000, 764.000000

This defines the width and height of the Cosmoid, as well as its location. You can either define a position from left and from bottom of the screen – or use “Center” on one or both to center it on the screen when loaded. The “Position” parameter is updated in real time when the user drags it to a different location on the desktop – and this is how it remembers its position after a reboot or re-logon.

Now for the elements. Right now, for starters, I support text labels, images, and buttons. Gotta start somewhere right?

[Content]
TextLabel = helloLabel, Hello Cosmos!, 250, 20, 25, 150, white, bold, 16

The syntax is as follows:
ID, string to display, width, height, from left border, from bottom border, text color, text weight (”bold” or “normal”), text size

Next is:

Image = sunImage, Resources/sunny.png, 90, 20

Syntax:
ID, image to display, from left border, from bottom border

Now with buttons it gets slightly more interesting as they do something or manipulate elements. They look like:

Button = sunChanger, Sun!, sunImage, setMyImage:, Resources/sunny.png, 100, 20
Button = rainChanger, Rain!, sunImage, setMyImage:, Resources/rainy.png, 200, 20

Syntax:
ID, text to display, ID of element to manipulate, action, parameter (or if none, put ‘nil’), from left border, from bottom border

So as you can see – you quite literally construct your Cosmoid line by line in a single file – it cannot be easier than that!

And I call it CML – Cosmos Markup Language.

Cosmoids have to be places in either: /Users/YOUR_USERNAME/Library/Cosmoids (for personal use only) or /Library/Cosmoids (system wide availability). The file that builds a Cosmoid is always called ‘cosmoid.cml’.

Obviously there’s gonna be a graphical construction tool for this, so don’t worry! Also Cosmoids can be configured via the Settings tool.

Okay so I made a really quick and dirty video to show the feature Grids, that I was (and still am) working on for my OS project, called laststep.

It is a virtual desktop solution built right into the desktop, you can turn this on or off.

So here goes…

In the last few days I have begun working on a solution for virtual desktops in my one-man-OS-project laststep. Tonight I have finished implementing important milestones for this feature.

Implementing this required extending the existing window class, it also required for both to be able to communicate with each other, the Desktop and Grids. It doesn’t do much other than displaying previews of open windows on its corresponding desktop, but that’s a start. The desktop the mouse hovers over is highlighted and slightly brighter than the others.

It is however possible to assign an application to a certain desktop. Right now this works with a cryptic command – but hey, the Settings tool comes eventually

What also works right now is movement between desktops. You open the overview, click on a desktop, you are taken there.

Ultimately I want to implement the functionality to drag windows from one Grid to another. This is the next challenge.

This service is fully integrated into the user interface and is completely automatic. You will be able to choose whether to use it or not.

Also, you can choose between 4, 9, and 16 desktops (2×2, 3×3, 4×4 grids).

Doesn’t look like much, but it can display open windows of each desktop, and lets you travel between desktops. Moving windows between them per drag and drop is coming.

Not very pretty yet, but hey – it’s just development.

Veni, Vidi, Codi.

P.S.: I designed the icon =)