LCARS Program Links

[orion24]

I really like the idea for those widgets and I think that the program title in the upper left is a good idea I like that alot, But I think that LCARS buttons in the upper right would look good also, you can use them to switch between major programs or functions that you use alot. As for the dropdown menu that's a toughie, I'll have to think about that for awhile.

 

[Jadzia]

Do you mean like a block of half a dozen buttons in the top right corner, which work like the quick start menu: including instant messenger and email - programs which are user-oriented rather than system-oriented?

One feature of lcars, is that it doesn't use icons. So some Windows features (like the quickstart menu) are not possible through an icon strip. So the shortcuts either have to go into a dropdown menu (on the system menu) or have a block of buttons (top right).

One thing I like about the buttons idea is that they can be different colours to indicate if you have new mail, if someone is calling you on IM, whether the call is tagged as urgent, or if your network connection to your mail server is down.

The way I have the layout at the moment is left-right balanced. If the program title was left justified, I'd be concerned that too much was happening on the left and too little on the right. You might think that's petty, but it's the sort of thing I notice in software if it's all squashed up at one end.

 

[orion24]

I like your idea better for the LCARS buttons, instead of having them for shortcuts use them for indicators, Very good idea Jadzia.

 

[Jadzia]

Ok I've done that: 6 buttons: IM, email + 4 unused.
I also think we should also start to consider what core applications should be written to ship with this. eg,
- file manager,
- text editor
- mp3 player
- media player
- web browser

Not sure how im and email will work just yet. Maybe access the free yahoo services, by emulating the YMSG protocols, etc? That'd be nice. I believe they allow that as well.


edit: I'm finding it awkward writing the scripts for defining the displays for this, so I've decided to divert my attention to make a full visual development environment for this software, where applications can be built like in visual C++, where widget variables, and event responses are accessible through object oriented code.

It's not actually that hard to extend this project by creating the vde. More difficult to write the script interpreter, which will have to be done anyway. But the end result is that we should have a full blown development suite for this system

 

[orion24]

Sounds Good Jadzia, Also how about an Incoming Transmission display that comes up when you have an IM or an E-Mail come in.

 

[Jadzia]

okay... I'd be concerned with that if the user was at the console at the time.

It would be an obvious Romulan tactic during battle to bombard your opponent ship's crew with emails, and then they can't use their consoles because "incoming transmission" keeps popping up centre screen as they're trying to aim the damn torpedoes.

But if we were AFK, I guess then it's ok.

But then, if we are AFK, which console should that signal be displayed on? It would have to be when we're AFK from a private terminal, like those in our own crew quarters, not applicable to machines in any public area.

Either way, it is a nice idea, but is more of an application feature than a operating system function. But we're right to be explore these things, so we know what protocols need to be made explicitly available (or explicitly unavailable) to applications.

thanks orion

 

[orion24]

You're right Jadzia, I didn't even think about that.

 

[Jadzia]

I was thinking this morning how the lcars interface is relatively cumbersome. After trying a few layouts for applications, I'm finding the widgets are more space consuming than in Windows, so the gui is relatively low density. This in turn reduces the functionality for the user. It's like being back on 640x480.

Making the widgets smaller and cramming more in, actually makes it difficult to read - the colours and shapes are just too striking for today's kind of computer interaction.

So I'm not sure what to do about that.



But I do have a cool idea...

You know how lcars doesn't use mice? But somehow they are able to manipulate objects on the screen with relatively few buttons.

I was thinking... we could still have virtual cursor, by fitting a camera which tracks the user's eye motion. The virtual cursor would be located wherever on the screen we are looking. This technology does exist for casual use - you don't need big headsets.

In implementation, there doesn't need to be an arrow pointer on screen because you know what you're looking at. Then a single button can represent the click action.

 

[orion24]

I understand Jadzia, Or we can always wait for this: http://www.youtube.com/watch?v=GqDQ0wUcSPQ Also I really suggest you join this site: "Okudagrams.com at: http://www.joseralat.com/forum/index.php they can help alot what with you're trying to do here I know they would also be very interested in this project.

 

[Jadzia]

I've discussed touch screens before I think.

In theory they're great, but in practice I think they'll be really awkward. If you keep bringing your hands up infront of the screen, then you can't see the screen, so you have to keep moving them up and down.

That'd be so irritating to be occluding your own view, and it'd quickly give you arm ache.


The only practical use for touch screens for desktop systems is with dual displays:
- One screen displays a relatively static input screen, like replacing a laptop keyboard. This is the touch screen.

- One screen displays a vertical output screen, like a normal monitor. This may also function as a touch screen but shouldn't be relied upon.


I think, what microsoft is making there for windows7 will be a bit of a fad. The response time in that video is awful too.

 

[orion24]

That's true also, I didn't think of that, Maybe if the screen was tilted at a 45 degree angle it might give you're arm a rest, Just a thought. Have you considered joining Okudagrams.com? Alot of members there are Tech minded like you, They can really help. I'm a member.

 

[Jadzia]

I'm on. Just made a post
username: Jas

 

[orion24]

Nice to see you made it there Jadzia.

 

[Bill Morris]

LCARS 24 doesn't use a mouse, yet drag and drop is accomplished with the arrow and ENTER keys in its Solitaire and chess games, and with the file manager a file listing is sent flying from one list to another by pointing with arrow keys then pressing an F-key, you can see one list expand while the other contracts, and the inline numbers in the buttons representing those folders change instantly to reflect those changes in numbers of files in the respective folders.

Many things you do with a mouse in conventional GUIs are done with labeled hot keys quickly and smoothly. You can certainly open, view, and close 10 files in rapid succession with LCARS 24 in a tiny fraction of the time it would take with Windows or anything like that. Iinput with the calculator is all keyboard, as it is with games like Sudoku and Kakuro, and it's faster and smoother than mouse-operated equivalents.

It's even possible to have a Web browser operate by keyboard only, where the right arrow key makes the pointer jump from one "click" target to the next on the current line and then go to the next line down that has a "click" target, etc. and the down arrow to make it skip the current line and send the pointer to the next one below, and well as scroll, and the reverse for the left and up arrow keys. Then you can "left-click" with the ENTER key. And direct scrolling is with the Page Up/Down, Home, and End keys. It's all faster and smoother than mouse operation.

 

[Jadzia]

LCARS 24 doesn't use a mouse...

Scrapping the mouse, in itself isn't a step forward. The user has to be given some superior method of directing the gui. Sadly, I don't believe your program does that. A dozen pushes of the arrow keys and function keys is slower and less comfortable than a simple mouse drag from A to B.

Many things you do with a mouse in conventional GUIs are done with labeled hot keys quickly and smoothly. You can certainly open, view, and close 10 files in rapid succession with LCARS 24 in a tiny fraction of the time it would take with Windows or anything like that.

I feel that Windows is pretty quick at selecting and viewing a series of files. And with software like IrfanView installed, I'd challenge your assertion.

Open/view/close many files is only a small part of a typical computer session. The idea of a good gui is that typical computer use should demand a minimal amount of user effort, and return a maximal amount of computer work. Now we can count that user effort in button pushes or mouse clicks, or the mental effort required to look up the action of a set of function keys / hotkeys, or whatever.

From what I've seen of your program when I tried it out first time you gave me a write up about it, I personally found that it required more effort to do trivial things. Whether that's scrolling a cursor around by repeatedly tapping the arrow keys, when it would be quicker for me just to use a mouse. Or having to read through a list of text to see which program/file I wanted to see. It reminded me a little of those old DOS applications, where you were required to press Alt and then 20 pushes of the arrow keys to go through the menus. It was because of the tedium of that procedure, that the mouse became so popular. I'd dread to think how tedious it would be to scroll around with arrow keys with 10000 viewable files installed. Or to sort them by name or date or size, or multi select them.


In conclusion, I am finding that this 'okudagram' inspired layout, common in much of this fanware, just isn't a suitable gui for conventional computer usage. Simply scrapping the mouse, and stepping back to that DOS-type interaction isn't, in my opinion, an advancement.

Maybe, if you can think of ways to upgrade the interface to accept higher level instructions, only then can we use a gimmicky gui, and rid ourselves of a mouse.

But while we're stuck with needing to provide methodical step by step instructions, then we need a gui that is functional and comfortable for that task: providing good access to many functions, like the mouse gives us, like shortcuts, icons, and like the start menus and quickstart menus give us.

 

[Bill Morris]

Well, LCARS 24 is designed for keyboard operation only, and I have no intention of adding mouse support. A laptop is not always used on a desk, in which case it should be operable without a mouse. And I don't recall seeing mouse operation of an LCARS computer on any Trek show.

 

[Jadzia]

This is because our objectives are different Bill, as I have explained before. You're making fanware, because "likeness to the Trek show" is your first and constant priority. So if trek doesn't have mice then neither do you. If trek has such and such a font, then so do you. If trek uses color &hffcc00, then so do you.

What I'm trying to make... I want a better interface. Introducing some trek elements would be nice, but this is a lesser priority. I'm not looking for mouse support... I don't particularly want it... I want a better interface.

 

[Hiroki_Ishiyama]

I just loged onto this web site for the first time i a while to anounce my LCARS project, only to find yall have done quite a bit of work on one.

But, here is what I am working on:

My LCARS interface is a compleate operating system, at the moment it is hosted on Linux, but I am in the process of creating a custom micro-kernel for it.
The base system (sound, graphics, networking, etc) are written in C.
The rest of the system is written in a language I wrote called CDc, it is ment to be a "safe" version of C.
CDc has near native exicution speeds, and has benched marked faster that Python and Java.
My Interface used a backed database system inspired from startrek.
It has a full-featured network sub-system, capable of creating masive networks over the current ip based internet.

This system is at best maybe 6 month away from being useable, BUT could use some help.
I need help developing the end user interface.

If any one is interested, feel free to pm me.

--Hiroki Ishiyama

 

[Jadzia]

This sounds interesting, especially with the linux kernel. Can you provide some piccies, plz



Some things I'd like to know:

How are you managing widget classes? Can these be easily custom defined, including their properties and event responses?

How are you managing multitasking?

How are you managing user security and data encryption? Nobody enjoys keying in passwords everywhere. Each user should be able to specify at point of login, what level of security clearance they want for that session. Then as long as the user is logged in, then security access should be granted to all the user's files upto that level, except for extra secure data and system functions which would demands additional passwords.

Also, the file system... can this be simplified somehow? With many PCs and drives at hand these days, I often get in a knot asking myself "Where did I save file X ?" and searching through a load of disks and memory cards to find it.

The ideal situation for me would be to have the option of saving to "personal" file space, or "internal drive" file space, or "portable drive" file space.

The last two are self explanatory. Personal space should be space accessible to me from any terminal, and in some way will follow me around. Maybe that involves background downloading from other storage devices if necessary. Or if I walk around with a bluetooth enabled storage drive, then it automatically connects when I login. Or maybe it involves uploading the file table (and download location) changes online somewhere? So that access to files across networks can be made as transparent as possible

 

[Hiroki_Ishiyama]

Thanks for the interest, to start with, everything written in CDc is exicuted in a VM.
The widget classes are managed via an api, eg you wand a button, you call an LCARS_Button api.
Security is a big one.
Basicly, when you authenticate with the "LCARS Command Network", you are assigned the security clearance given to you by the sysadmin. Your base credentials are stored in memory, and presented whenever you try accessing a diferant netwrok. Once the Command Network has authenticated you, anything on that network will accept your credentials, and if you have the clearance, give you access.

The file system is based off of the posix standard.
You have / ( slash or root ) and every this branches off of there.
You personal data ( home folder ) is stored in /UserData/<username>
The data you have deemed every one can access is stored in </UserData/<username>/Public and /DataBase/<username>
You can mark a file as public with out having to move it to you public folder.
removeable media shows up as a sub-folder in your home folder.

The backend file storage metod uses a distributed file system.
Your home folder is always your home folder, you log in at home, you see the same files as if you had loged in at your friends house, and vice versa.

As for multi-tasking, it is handled by the vm, a new vm thread is spawned when a new task is created.

The files in the file system are indexed, so you can say, "Computer finde me the file containing my pictures of the flowers from my vacation to spain" and the fs indexer finds the file.

As I mentianianed, this is still a work in-progress, with at-least 6 mos to go.
But, I have the base graphice and sound system working (tho not as well as I would like)
and I am working on finishing the file protocols.
I have just started the network protocols, They are rather advanced, and are going to take some time.

I plan on releasing a "bata" once the core system is finished, at that point, people could start writing programs in CDc to run on it.

--

Are there any other questions?


--Hiroki Ishiyama