One of the things I need for version 4.0.4 and beyond is a good system for naming the buttons to make it easy to declare them in SFML. I've started using letter codes that describe their shapes, like RR for round at left and round at right, SR for square left and round right, adding K where there is an inline number or symbol (which in LCARS 24 represents a key to be pressed), and B where part of the button is blacked out.
But there's more to it than that, since there are special short butttons, as well, and some other types seen on Trek that are not so useful without touchscreen. But this naming system has to make it clear what the button will look like and still hold up when and if other butttons not now in use are added. The letters F (for a square of fill) and G (for a gap) added might cover all that. Then the simplest button called RR would become RFR, since it is round left and right, and its width is three times its height, meaning there is a square of fill in the middle.
I've already got SFML panel displays with buttons diplayed in response to new commands, as well as the sort of flange divider seen on the Options menu and connection with pipe bends, etc.
Another thing is simplifying the coordinates, like button positions numbered vertically from 1 to 12 rather than having to specify them in pixels. Horizontal positions will be a little trickier, since button columns can vary in width.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been searching for and downloading LCARS screencaps, just to see what new types of buttons to include, and I will probably end up replacing two of the old button types that have been in LCARS 24 for years.
Both the naming system and method for making placement easy get a bit complicated, but the end result will be good.
And there have been various requests about adding functionality to SFML, like playing sound files, and those will be added, as well, probably with a fancy demo featuring new button commands, with sound output in response to key input.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Those short buttons on the VOY Ops console would be good in the Blackjack game, for the IN PLAY button when splitting hands, to replace the wider one used now. It would just look cooler, assuming there's room for the labeling. That's one thing to look into.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So R means round, F means fill, K means inline key label, and the rightmost R means round again. S as part of a button name means square. If a button is to have a gap, that will be indicated by a G.
The x= above is in pixels, and the y= is the column, which is nice but not so easy to do for the x coordinate.
Sure. Those commands already exist in verion 4.0.3. Look at the one about the Space Shuttle. Commands for playing audio files will be added in 4.0.4, as well. A command for running an .exe that doesn't produce any screen display could be added easily enough, but I'm not sure how useful it would be, unless you've got a setup to control peripherals from DOS programs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That screenshot is beautiful! Especially the round buttons with lines between them. Perfect for mindmaps.
Commands for playing audio-files will be useful as well. Not only for presentations. One could easily code an LCARS sound board now. :)
As for running exe's, if it's not hard to implement, please do so. If flags can be passed on to the exe's, it could certainly come in handy in some way. One example would be a file conversion program made with external utilities, to for example convert a wav-file into an mp3-file and back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to run an exe I've done, but conversion programs make DOS screen displays, unless I've got sources and can modify and recompile them. And to pass an argument, I'd have to diplay an input box plus a list of files in the folder. That's a lot for user-programmable functions that not many people would use, although it might be cool to have an SFML command to call an input screen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A file-conversion app is one of the things I was going to do later. It's on my list. I'd have to have sources to recompile various external conversion programs just to get started. I have exes for converting image files but not sources, and I'd have to find sources for doing that with audio files, as well. I'd have to have all that before even making an interface for it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If it'a an argument specified in SFML to an external exe, that's okay. I can put one like that on a demo page, which any user can modify or make others like it to call some program and pass arguments that way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Who would have thought it would come to this? Most people just drsw them with Illustrator or something like that, and even try to hybrid them with TCARS, etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This button organization also makes the inner workings of the LCARS system a little more efficient, besides adding flexible SFML commands for these buttons.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, this speaks to the kind of application LCARS was meant for. on small control panels not on PCs but future mountable screens to be used as switches or remote controls.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Those would have to have a form factor the tech doesn't support yet, thin and mountable on a wall. And they'd have to be a mass-market thing to be cheap enough. That means people would have to be able to select the style of the screen display after taking it out of the package, and LCARS could be one choice. If it's only LCARS, the market would be too small to keep the price in line.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One of the things I need for version 4.0.4 and beyond is a good system for naming the buttons to make it easy to declare them in SFML. I've started using letter codes that describe their shapes, like RR for round at left and round at right, SR for square left and round right, adding K where there is an inline number or symbol (which in LCARS 24 represents a key to be pressed), and B where part of the button is blacked out.
But there's more to it than that, since there are special short butttons, as well, and some other types seen on Trek that are not so useful without touchscreen. But this naming system has to make it clear what the button will look like and still hold up when and if other butttons not now in use are added. The letters F (for a square of fill) and G (for a gap) added might cover all that. Then the simplest button called RR would become RFR, since it is round left and right, and its width is three times its height, meaning there is a square of fill in the middle.
I've already got SFML panel displays with buttons diplayed in response to new commands, as well as the sort of flange divider seen on the Options menu and connection with pipe bends, etc.
Another thing is simplifying the coordinates, like button positions numbered vertically from 1 to 12 rather than having to specify them in pixels. Horizontal positions will be a little trickier, since button columns can vary in width.
As long as there are sufficient demos and documentation, that sounds workable.
I've been searching for and downloading LCARS screencaps, just to see what new types of buttons to include, and I will probably end up replacing two of the old button types that have been in LCARS 24 for years.
Both the naming system and method for making placement easy get a bit complicated, but the end result will be good.
And there have been various requests about adding functionality to SFML, like playing sound files, and those will be added, as well, probably with a fancy demo featuring new button commands, with sound output in response to key input.
Those short buttons on the VOY Ops console would be good in the Blackjack game, for the IN PLAY button when splitting hands, to replace the wider one used now. It would just look cooler, assuming there's room for the labeling. That's one thing to look into.
Here's the first demo page made with the new button naming system. The F1 button at upper right is called like this in the SFML file:
<RFKR x=552 y=1 color=lilac str="rfkr" keycolor=naples kstr="F1">
So R means round, F means fill, K means inline key label, and the rightmost R means round again. S as part of a button name means square. If a button is to have a gap, that will be indicated by a G.
The x= above is in pixels, and the y= is the column, which is nice but not so easy to do for the x coordinate.
Here's the screenshot:
http://i6.photobucket.com/albums/y247/LCARS24user/BUTTONS-1.png
And a panel like that will be able to call up other panels, etc., right?
Sure. Those commands already exist in verion 4.0.3. Look at the one about the Space Shuttle. Commands for playing audio files will be added in 4.0.4, as well. A command for running an .exe that doesn't produce any screen display could be added easily enough, but I'm not sure how useful it would be, unless you've got a setup to control peripherals from DOS programs.
That screenshot is beautiful! Especially the round buttons with lines between them. Perfect for mindmaps.
Commands for playing audio-files will be useful as well. Not only for presentations. One could easily code an LCARS sound board now. :)
As for running exe's, if it's not hard to implement, please do so. If flags can be passed on to the exe's, it could certainly come in handy in some way. One example would be a file conversion program made with external utilities, to for example convert a wav-file into an mp3-file and back.
Just to run an exe I've done, but conversion programs make DOS screen displays, unless I've got sources and can modify and recompile them. And to pass an argument, I'd have to diplay an input box plus a list of files in the folder. That's a lot for user-programmable functions that not many people would use, although it might be cool to have an SFML command to call an input screen.
A file-conversion app is one of the things I was going to do later. It's on my list. I'd have to have sources to recompile various external conversion programs just to get started. I have exes for converting image files but not sources, and I'd have to find sources for doing that with audio files, as well. I'd have to have all that before even making an interface for it.
If it'a an argument specified in SFML to an external exe, that's okay. I can put one like that on a demo page, which any user can modify or make others like it to call some program and pass arguments that way.
Maybe the Options menu is going to change, with buttons more like the rows of buttons seen on Trek? Or is it less functional like that?
That could be used in fanflims, save somebody a lot of work.
Who would have thought it would come to this? Most people just drsw them with Illustrator or something like that, and even try to hybrid them with TCARS, etc.
This button organization also makes the inner workings of the LCARS system a little more efficient, besides adding flexible SFML commands for these buttons.
So there will be functional examples, too.
At least one for playing sound files, since there will be SFML commands for that.
Good, but this is why so much time passes between releases, it would seem.
Well, this speaks to the kind of application LCARS was meant for. on small control panels not on PCs but future mountable screens to be used as switches or remote controls.
That would be nice if they were configurable so people could write themes for them. They'd have to be very thin and mountable. And cheap.
Those would have to have a form factor the tech doesn't support yet, thin and mountable on a wall. And they'd have to be a mass-market thing to be cheap enough. That means people would have to be able to select the style of the screen display after taking it out of the package, and LCARS could be one choice. If it's only LCARS, the market would be too small to keep the price in line.
At least having these buttons and other SFML capabilities creates one more way of having fun with a computer.
This what I'm trying to do and the reason I put an EDIT key label on SFML pages.