OSD the Next Generation :-)

[Ron]

So people please get a discussion going about the new features that an OSD should have in your mind. Please be as descriptive as you can!

[Ron]

Okay! sounds like a must :D

[Ron]

Good suggestions! I´ll give them a lot of thought. With most i don´t see a problem. Only these 2

DirectX overlay,... hmmm does anyone have a code snippet how to do this ?
HTML ... Gecko or IE *shrug* ?

Regards,
Ron

[Ron]

Glad to see we are thinking along the same line Mark.

[Ron]

That would be great Jeff!! I'll drop you an email, looks pretty nifty that OSD !

-Ron

[Ron]

The fonts are customizable in the OSD, just look in the settings dialog, the last tab.

<font size=-1>[ This Message was edited by: RonB on 2001-07-17 23:44 ]</font>

[Ron]

I see there is interest for the source, well then I just have to make some time. :wink: The OSDPopup source has been uploaded. Enjoy.

[Ron]

Sounds very good. Programming this is a nice challenge. If only there where 48 hours in a day.

[JeffK]

Guys,

I have no experience developing Girder plug-ins, but what I do have is a C++ class called OSDWnd that I wrote for my caller-id application.

It doesn't do everything that you guys are talking about it, but it might serve as a good starting point.

I've been thinking about adapting it as a Girder plug-in, but I'm not really sure when I would have the time. I'd be willing to donate the OSDWNd class, though, if somebody else wants to run with it. It's an MFC C++ class.

You can see the OSD in action, by downloading my caller-id app (http://home.houston.rr.com/jkohn/files/CallerIDSentry.zip) and using the 'Test OSD' button on the options dialog.

If somebody is interested in the code, email me at jkohn@houston.rr.com, since I don't always remember to check these forums.

Jeff


<font size=-1>[ This Message was edited by: JeffK on 2001-05-13 21:57 ]</font>

[Mark F]

You asked for it. :) I have actually been compiling a list for a possible PopUp plugin enhancement in the distant future. (about the same time as when everyone has flying cars) :)

I've seen others ask for some of these and thought they would be useful or cool. I made up the rest. An OSD doesn't need to have ALL of these, the list just seemed like a discussion starter. Enjoy.

--------------------------------------------

Programable level of transparency. (0%-99%; could have distinct intervals like 0, 10, 20, etc.) This would allow fade in/out.

Programmable size and location. Must support multi-monitors.

Programmable persistance time (including infinite).

Either import of graphics and display at specific locations or simple shape and text drawing (with control over line widths, colors and fonts) to allow the creation of "buttons".

Ability to choose the above buttons via an input device and tie this choice to commands in the tree.

An option to auto-size the OSD window to the text/graphics being displayed.

An option to show/don't show OSD over DirectX applications (games, et al) and applications using overlays (DVD players, dScaler, et al).

A way to replace the built-in OSD component (OSD plugin) so someone else can build the "perfect" OSD. :)

Support for HTML or some other mark-up language.

[Mark F]

DirectX - I don't know, that is one reason I haven't done it. :)

HTML - Again, I'm clueless. However, I would suspect that if you look around for a FREE HTML parser/renderer component, you'll find your answer.

Here are some of my other random thoughts on the Girder OSD and the reasoning behind those thoughts. Some of these are a break from the current model. This shouldn't be misconstrued as disrespect for Girder or you, Ron. These are just thoughts and possibilities for moving forward. In the end, I'll use what you provide. :) So far, it has been the BEST and I have no reason to think the future holds anything different.

1) I think the OSD should be just another SW plugin because ...

You could upgrade the OSD without impacting the Girder event router. This makes Girder more modular, allows me, as a user, to remove or replace a part of Girder that I may not use or use differently, etc.

2) I think the OSD should have a "command" UI because ...

The USER, not the plugin writer, should decide what content goes into the OSD and when/how the OSD is displayed.

3) I think the OSD programming IF (for use by other plugins) should go away because ...

I've used the current programming model and it works pretty well for a limited set of function. To expand it to include a larger set of function, like the above requests, will require MANY new interfaces, new data constructs, etc. I really think your time would be better spent on function and new plugins rather than new OSD programming interfaces. I'm trying very hard to come up with a reason why a plugin needs to use the OSD programming interface (other than to be an OSD PopUp plugin) and can not. Maybe someone can help me with my obvious short-comming. What other plugins use the OSD interface? Also see the reason for #2 :)

4) I think source for a functioning OSD plugin (maybe one with the current OSD PopUp function but expanded to creatw the window and drawing context) should be included in the developer SDK because ...

This allows expandability, replacement, etc. with a smaller learning curve. It allows hacks, like me, to crank out more and better plugins. :)

OK, I'll stop, for now. :) I have a couple of hours before the sun comes up, maybe I can crank out Beta 5 of the serial plugin????

[Mark F]

Just a couple of thoughts as I sit here eating lunch. :smile:

I sent the source for V2.0 to Ron the same time as the executable. As he gets some free time, I'm sure it will show up on the developer's page.

Expanding the global defaults (size, position, color scheme, etc.) should be pretty straight forward. These global defaults could be placed in the registry just like the custom colors are today.

Expanding the information that is kept on a per-command basis must be limited because most of the variables in the per-command space are already taken up with values. There are 5 ints, 3 bools, 2 char* and 1 byte that can be used for data. Right now the code makes use of 5 ints, 2 char* and 1 byte. Since one of the ints is used as a pool of bits and it is not full, that leaves a total of 3 bools and 8-16 bits (I don't have the code handy) for possible new per-command data.

New image types should fit in the bit-pool pretty easy (support for 4 types is only 2 bits).

Exact OSD window position/size takes 4 ints and won't fit.

"Transition" type could fit (again, in the bit pool).

Transparency isn't supported on most of the Windows platforms. The "correct" behavior needs to be thought out when transparency is not supported.

Someone with more DirectX knowledge than me needs to understand how the exclusive mode bit of DirectX can be over-ridden. After all, the exclusive mode application doesn't expect it so would it recover?

Oh well, back to the grind.

[Mark F]

Without seeing the code I can't say I understand why different file types would actually require any of the bit flags, but since you know the code and I don't, I'll have to wait till its posted =].
You're right, if the code triggered the image type based on the file extension (not reliable) or file contents (not reliable). Instead, I would have the user tell the software what type of file they are using and save this information in the per-command data. :smile:

As far as the exact on screen positioning goes, the 5 choices currently in place would be plenty if the user could tweak the default anchor point for each one. This should be relatively easy to accomplish and require zero bits.
That sounds pretty do-able. With the current number of bits used (3), you could define 8 locations or maybe leave the current corners/center (5) and have 3 floating.

Anyway, I wish you luck. :smile:

EDIT: BBcode mess-up
_________________
Mark F

<font size=-1>[ This Message was edited by: Mark F on 2001-10-24 14:07 ]</font>

[jediperry]

The most importnat one as far as i'm concerned it the being able to specify the background colour for different situations. i.e. The background for my TV card is the normal pink overlay colour, but the holywood+ uses black overlay.

Cheers,

Mike

[jediperry]

This would be a cool way to select between different groups as well.
Depending on how Ron writes it, it wouldn't necessarily need to be able to take inputs, as girder could just update the OSD after a key press i.e make one piece of text bold whilst un-bolding(?) the other options.

Mike

[lesterjacobs]

Hi,

I've got a slightly different slant on the OSD idea. The current suggestions are really good but I would like the OSD to also be input capable. What I mean is, most infrared remotes( or other input devices) don't necessarily have all of the keys that you want. Therefore it would be great to be able to put a list of options in an OSD and be able to choose from these options using the remote.

The specific idea I have in mind is the ability to launch programs. I would like to have a configurable list of choices appear in an OSD, then use my remote to highlight the appropriate one and choose it which would then launch the corresponding program. At a minimum then the OSD should associate certain keys on the remote with previous item/next item and select item.

The functionality I am talking about would be similar to the OSD available on some monitors changing settings.

Cheers
Lester

[BSchuler]

Ron,
I don't know the first thing about OSD programming. Bearing that in mind, How about a way to import any graphic (a size limit is fine) and turn it into an overlayed OSD graphic.

An example of this is, say I want a specialized overlay that says TV ACTIVE and a small pic of a TV. I could make my own graphics, then import/convert them. Then use Girder to show the picture when I want to (you could use state based on reg value for volume, etc).

If the import idea is possible, I think it would solve all problems in one fell swoop. No matter what OSD someone wants, they could just make it themselves. Otherwise Ron, I fear someone will always ask, CAN YOU MAKE THE OSD LOOK LIKE THIS?

If import isn't possible, how about an OVERLAY editor?

Personally, I have no problem with the OSD the way it is......But reading the messages I know someone will ask this, so I thought I'd beat them to it.....Plus, I saw where in future versions you were considering the graphic idea...

[Bates]

Couple nice features would be the ability to have NO background (i.e. a transparent background) and the ability to draw a bar graph given a 0-100% value. Orientation for the bargraph would be a nice thing also, so that one could have a vertical bargraph if so inclined.

One other thing comes to mind would be to have a lable followed by 'ON' or 'OFF' with the state of ON or OFF coming from a numeric register.

Jim

[JayGuerette]

Having an HT/XML interface certainly offers the most exciting possibilities for an interactive OSD. The easy part would be the OSD itself, merely embedding an IE object in a window, the same way Winamp does with their mini-browser. The http server itself is simple, the tricky part would be exposing an object model through an http interface. The ability to customize the interface with graphics and form elements is compelling. Microsoft only recently figured out alpha transparency in Win2K, so most people would be stuck with a solid background. I personally don't see that as a detractor.

[theguru]

I mentioned this in another post about Soundblaster live fader not working...

Some ideas :

Including the volume control as a particular type of OSD, so for example you could use it to control the Brightness of your montor through your video card. Also more options as to the way the lines are drawn, eg a Up & Down fader bar as well, etc.


Being able to put icons up for Volume, balance, fader, bass, treble, contrast, brightness etc, etc.

Perhaps even some simple sort of generic graphing (maybe using a HTML/XML type language) to achieve the volume controls so they can be customized..
(Some people may want to colour code them from Green to yellow to Orange to Red as the volume is increased etc).





<font size=-1>[ This Message was edited by: theguru on 2001-07-01 16:54 ]</font>

[anton]

here's the thing that I miss very much : customizable fonts ,because I can't even read those little fonts on my TV (it's not very good :sad: ) and maybe size of the window rectangle

thanks a lot

[anton]

Oh, thanks, I see now :smile: ...

[mattwire]

Just a couple of suggestion for the new OSD:

1)Transparent background - could just be a simple option for text based osd's but for a graphic osd you could set a mask colour.

2)Flexible positioning/size - eg left/right/top/bottom screen align + absolute positioning (using percentages so it is resolution independent).

3)If possible osd that will work when apps are using the screen in exclusive mode so they are not minimized just to display the osd - I realise this is probably not possible! but...

[mitko]

Guys it's been a long time since the last post in this topic but I suppose that someone is still working on this "Next Generation OSD PlugIn". Is there any progress? If so I'd like to participate in the testing or even in the developing, though I had never tried creating a plugin for Girder.

[cranky]

1) Better integration into girder.
Having to create a multi-group for every event I want to have a OSD for is a pain. Being able to enable the OSD checkbox for events other than for example volume or mute would be handy.

2) More OSD defaults (other than font).
I use a black background, red border and white text for my menus, having to select them for each OSD can be annoying. Display time and position must also be set seperately for each OSD command.

3) Flexible positioning and size.
Being able to set a fixed size and position for OSDs would be nice.

4) Better image support.
a) ability to load other than bmp files (jpg, gif)
b) ability to load an image as a background for text.
c) BUGFIX - if there is no text message, the current version won't show the bitmap at all if there is no text message and "shrink window to smallest size" is checked.

5) custom OSDs for standard functions (volume, mute).
It would be nice to be able to create a image or sequence of images for volume and mute for example, or at least be able to change the colors on them.

6) Transitions for display and removal.
For OSDs with images that are positioned center screen, they fold out from the center, if they are positioned in the lower right they expand from the right side of the screen. User selectable OSD transitions just as fade in, fade out would be nice (but low priority)

7) Source code to version 2.0
I'd love to hack these things into the OSD myself but I honestly don't have time to write the whole thing from scratch.

Now the question is, is anyone still working on a new OSD? =]

Thanks,
cranky


<font size=-1>[ This Message was edited by: cranky on 2001-10-21 10:03 ]</font>

[cranky]

Hey Mark,

I saw in another thread that you had sent the code to Ron, thanks for contributing your hard work to the community.

Personally I'm not very concerned about having every last feature customizeable on a per command basis. A good set of defaults and some well planned per command options I think would kick major butt.

Without seeing the code I can't say I understand why different file types would actually require any of the bit flags, but since you know the code and I don't, I'll have to wait till its posted =].

As far as the exact on screen positioning goes, the 5 choices currently in place would be plenty if the user could tweak the default anchor point for each one. This should be relatively easy to accomplish and require zero bits.

With the transitions, I'd be happy with maybe a default user selectable transition and maybe a disable bit for commands that you don't want it for. As far as transparency support, there are ways to "fake" it if someone was so inclined. Personally its not all that important to me, but would be nice.

Unfortunately I don't know much about Direct X :sad:. But hopefully someone else does or I can enlist someone to help out =].

Thanks for the information.

[cranky]

I started looking at the code and became busy with work that actually pays the bills, but I have not forgotten about the PopUp OSD. Hopefully I can devote some actual time in the coming week. I just didn't want anyone to think I was a wanker screaming for code and then not doing anything with it.

-cranky

[mikey88]

I'm not sure if anyone pointed this out before:
Transparent background for the OSD is nice, but if you do it along with Alpha Blending (Win2k and XP support this) for the message itself then this is simply irresistible!

[Lemmi]

Hi Guys,

You ask about features for a new OSD ?
Here are my 'brainstorms':

-------------------------------------------


The user can define any numbers of objects.
A Object is:
[list:76fc23e8c8]
a bitmap
a text line
a textbox
...

Every kind of objects has is own attributes.

You can arrange the item in TeX like styles (hbox,vbox,hfil,vfil).
This means:
You order some objects vertically or horizontally together to one new object.
You do this recursivley: This new object can be combined with any others object
to a next new object.

If two or more Object are combined, perhaps vertically, you must align
this with horizontal spacings to bring them into the same width.
These should be done with stretching factors.
For this it is also good to have an empty element defineable size.

After arranging und positioning of the objects every object will be drawn at his place.
[/list:o:76fc23e8c8]

-------------------------------------------

Here is an example:

The Syntax:

'(name)' uses one defined objects
'V[...]' means vertically box
'H[...]' means horizontally box
'L', 'C' or 'R' means default alignment left/center/right in vertcally boxes.
'T', 'C' or 'B' means default alignment top/center/bottom in vertcally boxes.
'E(x,y)' defines an empty/invisible object.
'S(n)' defines an skip: vertically or horizontally.
S(5) means 5 Pixel space.
'*factor' specifies an stretch factor.
Without any stretch factor in a row/columns the default alignment is used.
Without any stretch factor and without default default alignment space is
placed around all objects.

If 1 stretch factor is defined, the objects consume the whole additonal space.
If 2 or more stretch factors are defined, all objects consume the additonal space
belonging the factors: A *6 object takes 2 time the space that a *3 object takes.


I want the following: ( I hope that you can see this text grapic ! )



+-------------------------------------+
| A centered text at the top |
+-----------+---------+---------------+
| | | |
| a bitmap | a | a bitmap |
| here | little | here |
| | space | |
+-----------+---------+---------------+
|A left aligned text here. |
+-------------------------------------+


Here is the construction script:
'V[ C(text-1) S(5) H[ T(bitmap-1) S(10)*1 T(bitmap-2) ] S(5) L(text-2)]'

Remarks:

The bitmaps are alignd at top.
'S(10)*1'[/b] * defines a 10 width pixel space. If one of the both texts is wider than the 2 bitmaps + 10pixel together, the space is stretched, because it os the only object with stretch factor.


-------------------------------------------

The net question is: How do this data fit into a Girder command:

Store the contruction script into 'SVALUE1'.
Store the object infos into 'SVALUE2'. Use this sheme:
'name1=(type,attributes,...) name2=(type,attributes,..) ...'


-------------------------------------------

Lemmi, dc@18xx.de


<font size=-1>[ This Message was edited by: Lemmi on 2001-11-25 20:37 ]</font>

<font size=-1>[ This Message was edited by: Lemmi on 2001-11-25 20:42 ]</font>