Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: New Foobar GUI (Read 219097 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

New Foobar GUI

Reply #25
updates for me just fine... I LOVE HOW IT SNAPS TO THE SCREEN...

DANZ you rock

New Foobar GUI

Reply #26
Quote
Quote
Just one more thing, the song name doesn't seem to get updated when the song changes or you change the song.


That's def. implemented and working fine for me and Aero.  Volton?

Nevermind, I'm an idiot

New Foobar GUI

Reply #27
Having a bit of a problem here

Every time I launch fb2k with foo_wsgui.dll in the foobar directory the entire PC immediately locks up tight.  Only a hard boot brings it back.

I've tried removing other plugins to see if there was a conflict but it doesn't seem to matter.

The lock up occurs after fb2k is up but before the gui is even painted on the screen, so there are no error messages.

Running:

fb2k .62a
Win XP Pro w/SP1
plenty of disk and memory

Otherwise it work's great

Any thoughts?
Master of Fate. By Fate Mastered

New Foobar GUI

Reply #28
Found the problem.  There seems to be a conflict between wsgui and another program I run called Winbar which monitors system resources (in the same vein as Samurize or CoolMon).  Might be something to do with the way it's painting the screen ?
Master of Fate. By Fate Mastered

New Foobar GUI

Reply #29
Millions of thanks!
Can't wait for it to work on my Win2K.

As promised, I'm ready to take part in creating a simple cusomizable interface design format (skins)

New Foobar GUI

Reply #30
Non-XP users can install GDI+ by downloading and installing Microsoft's GDI+ Redistributable

If you are running Windows 98, ME, NT, or 2000, you'll need this library before you can run this component.

New Foobar GUI

Reply #31
I can see myself having a loyalty problem between this and ufts as this develops!!

I'm envisioning:
the title (which will be a customizable TAGS string of course!) scrolling slowly
perhaps right click and drag anywhere on the window rather than a drag area?
ufts' right click menu

um not much more really needed
nice job!

New Foobar GUI

Reply #32
mhm. I really love this plugin !!!!!!

And it looks really promising. I don't want to post ideas and suggestions (or feature request) now, since DanZ only wanted bug reports...
But I will surely do this later ;-)))))))))))))))))

Bug Report:
Unicode seems broken. fpr eample "Stürmer" becomes displayed as "Stürmer"

New Foobar GUI

Reply #33
Quote
I can see myself having a loyalty problem between this and ufts as this develops!!


Who says they have to be exclusive?

foo_ufts (always on top off) - foo_wsgui (always on top on)

Thanks, Aero for the image.


New Foobar GUI

Reply #34
Quote
mhm. I really love this plugin !!!!!!

And it looks really promising. I don't want to post ideas and suggestions (or feature request) now, since DanZ only wanted bug reports...
But I will surely do this later ;-)))))))))))))))))

Bug Report:
Unicode seems broken. fpr eample "Stürmer" becomes displayed as "Stürmer"


What unicode support  - I haven't addresssed that yet.  Right now I just want to hammer out the general behavior of the UI and a "skin" format.  I'd take suggestions on both of those.

Check out the supplied foo_wsgui.gif to see how how the "skin" is currently constructed.

My current thought is to have the graphic in the current or some modifed layout and then a text file that will define the rectangles for the different buttons, the colors for fills, border, etc. The font(s) and sizes and colors.

These 2 files would define the "skin".

Other ideas?

Other things that should be in the skin?

New Foobar GUI

Reply #35
Quote
Quote
I can see myself having a loyalty problem between this and ufts as this develops!!


Who says they have to be exclusive?

foo_ufts (always on top off) - foo_wsgui (always on top on)

Thanks, Aero for the image.




My, my that has come a long way since the beginning! I looked at it when you first made it but to be honest LED style displays don't appeal to me at all (especially on a fully versatile display such as a computer monitor!). It is also a little on the large side and over the top for me.

What appeals about WSGUI is the size and the simplicity. Also the use of a normal font is so much nicer than the LED or square styles that some people seem to love so much but are actually less legible.


New Foobar GUI

Reply #37
Quote
Right now I just want to hammer out the general behavior of the UI and a "skin" format.  I'd take suggestions on both of those.

Check out the supplied foo_wsgui.gif to see how how the "skin" is currently constructed.

My current thought is to have the graphic in the current or some modifed layout and then a text file that will define the rectangles for the different buttons, the colors for fills, border, etc. The font(s) and sizes and colors.

These 2 files would define the "skin".

Other ideas?

Other things that should be in the skin?

Ok, so currently the top half is the standard display and the bottom is the mouse over for the buttons and the "completed" part of the progress bar?

Right. It all depends on how customizable you are aiming for. I think that sacrat would like something akin to the Winamp 3 skinnable interface. This is doable but I think would take a lot of work on your part.

I think that your idea of a graphic file and a text file to define the skin is the most obvious and sensible.  Perhaps having a few more basic shapes that can be defined (circles, triangles), though I'm not sure that would be worth it?

Also having more than two states in the image might be nice. By this I mean currently:
State 1 (top half of image) = mouse over anything but the buttons
State 2 (bottom half of image = mouse over buttons and completed progress bar

It may be useful to have more such states and have them more flexibly defined:
State 1 (defined in the text file as a rectangle/shape in the image) = no mouse over
State 2 (ditto) = mouse over window area != active areas (buttons)
State 3 (ditto) = mouse over active areas

I don't know if that is clear or not.

Having an object which is a TAGS display area which could be placed as defined in the text file would be great too. So the text could be placed anywhere in the skin. Having the text able to be auto-scrolling would be very nice too.

Feel free to rubbish any or all of my ideas/suggestions I won't be offended. Constructive criticism makes the world go round

New Foobar GUI

Reply #38
Quote
Ok, so currently the top half is the standard display and the bottom is the mouse over for the buttons and the "completed" part of the progress bar?


Correct.  Simple and easy.  I did it this way to reduce the number of rectangles you need to define and can use those rects + an offset (the height of the background) to look up the other button states.  The only downside is that you (depending on your design) be replicating the background image needlessly since all the states have to be the same size and layout.  But with compressed graphics formats and the generally small UI design this is not really an issue.

Quote
Right. It all depends on how customizable you are aiming for. I think that sacrat would like something akin to the Winamp 3 skinnable interface. This is doable but I think would take a lot of work on your part.


I want a balance between customizable and simplicity.  I don't want to go as extreme as winamp (although I need to review their skin format to see how robust it really is - I'm not that familiar with it).

Quote
Also having more than two states in the image might be nice. By this I mean currently:
State 1 (top half of image) = mouse over anything but the buttons
State 2 (bottom half of image = mouse over buttons and completed progress bar


Yes, that is the current setup. But I agree to more states.  I want to add rectangles for shuffle and repeat which will require a third state for the "toggle on" condition.

There could be cause for a disabled state too but I don't see the need yet.

Quote
I don't know if that is clear or not.


"Neo: Yes, Mr. Rhineheart, perfectly clear"

Quote
Having an object which is a TAGS display area which could be placed as defined in the text file would be great too. So the text could be placed anywhere in the skin. Having the text able to be auto-scrolling would be very nice too.

Feel free to rubbish any or all of my ideas/suggestions I won't be offended. Constructive criticism makes the world go round


All good, Constructive points.

The TAGS display is a good idea.  I could make the rectangle definable and also the show behaviour (always, on rollover window, etc.).

I like that...

New Foobar GUI

Reply #39
Quote
These 2 files would define the "skin".
Other ideas?
Other things that should be in the skin?


; intoduction:
; anything in square brackets is parameter.
; anything between brackets is parameter's value
; anything from ";" symbol to the end of the line is comment
; each skin consits of two files, FILENAME.bmp and FILENAME.txt, packed into a single ZIP file. ;Both file names must be the same.

; information about images is given in brackets in (X,Y,X2,Y2,X3,Y3) form or in HEX via #sign...
; here
;X1,Y1 means button's left top pixel on skin image, X2,Y2 define its right bottom pixel.
;All inside this rectangle is button. X3,Y3 define position of left top pixel inside background image.
;If last two values are not defined, buttons are considered to be placed iside Background image rectangle

;Foo_WSGUI skin specification ver 0.1

;skin information

[skin name]
; 2B dislpayed in skin selector
[skin author]
;we need to know herow 
;just to be displayed in skin selection dialog

;skin image settings
[BG]
;background image
[con_prev]
; "previous track" button.
;button's position on the skin file is stored in (X,Y,X2,Y2...) format.
;leave empty if there should be no button.
[con_stop]
; "stop" button.
[con_pause]
; "pause" button.
[con_play]
; "play" button
[con_next]
; "next track" button
[con_eject]
; "add" button. its behavior is set below
[eject_does]
; defines behavior of "eject" button.
; add_files = add files to playlist
; add_dir = add directory
; open_files = open files
; open_dir = open directory
; con_menu = opens context menu a-la foo_uftS
[con_volume]
; "volume" control button/indicator
; stored in (X,Y,X2,Y2...) format
[volume_displays]
; volume control's additional parameters (leave if none):
; H (X,Y,X2,Y2...) = horisontal volume state indicator, displayed inside "con_volume" rectangle.
; V (X,Y,X2,Y2...) = vertical voleme state ndicator, displayed inside "con_volume" rectangle.
;numbers in branches define background image. maybe, color in HEX?
[con_progress_BG]
; progress button indicator's background image (color)
[con_progress_FG]
; progress button indicator's foreground image (color)
[time_font]
;Font and parameters for time display in format:
;Font_name,font_size,style,H,V offset (from the BG image),Align,Color
;so Tahoma,8,Bold,10,1,center,000000 means
; Tahoma font, size 8, bold, offsets are 10px horisontal, 1px vertical, centured, black

; additional parameters
[info_BG]
;background picture for "information" display
;as its size is the same, as of background,
;we only need to define topmost left pixel's coordinates
[info_font]
;font for Atrist/title display
;=============================================

Any comments/wishes?

maybe, we can place "info" as a separate window?

New Foobar GUI

Reply #40
Quote
Any comments/wishes?


I wish you were programming it now

I'll need some time to digest that and I think we should get feedback on it before I do anything programming wise.  It is going beyond Simple  Both the format and the inclusion of the zip file reading and a skin browser.

My first idea was something like this for the file format.  For choosing the active skin you'd just go to the prefs menu and select the file name (of the skin text file) that you want to be active.  (I have code for reading files in this format from another project:) )

//A comment

section background
int width 200
int height 20

section play
int x 25
int y 25
int width 50
int height 50

section title
int displaymode 0 //0 = rollover, 1 = always on
int x 0
int y 0
int width 200
int height 10
string font "Verdana"
int fontsize 8
int style 3 // bitmask where 0 = normal, 1 = bold, 2 = italic, 4 = ?? , and so on

and so on for the other hotspots...

Question:  Should the title format specifier (TAG) go in the skin file as a paramter or in that prefs menu and then applied regardless of skin.  So, TAG is per skin or global for the plugin.

And, regardless of skin format this is going to take some time to program...

New Foobar GUI

Reply #41
Quote
Quote
Any comments/wishes?


I wish you were programming it now

I'll need some time to digest that and I think we should get feedback on it before I do anything programming wise.  It is going beyond Simple  Both the format and the inclusion of the zip file reading and a skin browser.

My first idea was something like this for the file format.  For choosing the active skin you'd just go to the prefs menu and select the file name (of the skin text file) that you want to be active.  (I have code for reading files in this format from another project:) )

//A comment

section background
int width 200
int height 20

section play
int x 25
int y 25
int width 50
int height 50

section title
int displaymode 0 //0 = rollover, 1 = always on
int x 0
int y 0
int width 200
int height 10
string font "Verdana"
int fontsize 8
int style 3 // bitmask where 0 = normal, 1 = bold, 2 = italic, 4 = ?? , and so on

and so on for the other hotspots...

Question:  Should the title format specifier (TAG) go in the skin file as a paramter or in that prefs menu and then applied regardless of skin.  So, TAG is per skin or global for the plugin.

And, regardless of skin format this is going to take some time to program...

I think this is more readable than SacRat's format (sorry SacRat) and if you have the code already then it makes a lot more sense to use that. The file sizes are going to be tiny relative to ANY audio file the user might have so there is no problem with being verbose especially when it makes for clarity. As people will be creating these text files by hand (no automated tools) it makes sense to put clarity before compactness.

need another displaymode for the title (autoscroll).

For the TAG issue I think that you can have both worlds - have a global TAG for the plugin, set in the plugin prefs menu but allow a TAG format to be suggested in the skin file and then have a check box "override skin TAG with global TAG". Obviously need to default to something (the global) if there is no TAG specified in the skin.

Take your time with it all  it's nice enough of you to consider doing at all.

New Foobar GUI

Reply #42
Surely, danZ, your format is much simpler.
But what about flexibility (eternal questions)...
My format allows using images of any size, have any position and much more.
Yours is a way simpler...
What do you think yourself? Create something flexible (hard to do and implement) or reply eternal: "I wanna replace a button".
I'll be happy to have simpler skin format, even like one from  Aston (www.astonshell.com) I mentioned above. VERY simple, but VERY powerful. Not too flexible  Sorry, I'm a maximalist
IMO it's faster to program somewhat like its clone...
Any ideas?
Quote
Question: Should the title format specifier (TAG) go in the skin file as a paramter or in that prefs menu and then applied regardless of skin. So, TAG is per skin or global for the plugin.

I'd loved to have both, but if manual skin format comes first. E.i. if you disable manual string, program uses one in skin.

P.S.: I prefer absolute coordinates in graphics...

New Foobar GUI

Reply #43
Quote
Surely, danZ, your format is much simpler.
But what about flexibility (eternal questions)...
My format allows using images of any size, have any position and much more.
Yours is a way simpler...
What do you think yourself? Create something flexible (hard to do and implement) or reply eternal: "I wanna replace a button".
I'll be happy to have simpler skin format, even like one from Aston (www.astonshell.com) I mentioned above. VERY simple, but VERY powerful. Not too flexible  Sorry, I'm a maximalist
IMO it's faster to program somewhat like its clone...
Any ideas?


My format will be completely flexible for sizes, locations, etc. its just an easier to parse and read format.

Here is a sample I'm currently working with.  It will make more sense once I release v .02 and you can try it out yourself.

section skininfo
//Information about the skin
string name "WS Default"
string author "DanZ"
string date "May-09-2003"
double version 0.1

section background
string filename "foo_wsgui.gif"
// Displayed width and height not the height of the entire graphic
int width 356
int height 15

section prev
int x 0
int y 0
int width 12
int height 15

section pause
int x 13
int y 0
int width 12
int height 15

section stop
int x 26
int y 0
int width 12
int height 15

section play
int x 39
int y 0
int width 12
int height 15

section next
int x 52
int y 0
int width 12
int height 15

section volume
int x 65
int y 0
int width 12
int height 15

section progress
int x 76
int y 3
int width 200
int height 9

section title
bool mouseinput false
string fontname "Verdana"
int fontsize 8
int x 0
int y 0
int width 356
int height 15

New Foobar GUI

Reply #44
Works great with Win2K.
Don't have any suggestion, just try to keep it light and simple if you want to make skins, we don't need another Winamp3 or Sonique 2 around 

New Foobar GUI

Reply #45
Quote
Works great with Win2K.
Don't have any suggestion, just try to keep it light and simple if you want to make skins, we don't need another Winamp3 or Sonique 2 around


"Cypher: Don't hate me, Trinity. I'm just the messenger..."

I'm keeping the skin format simple but I can't be held responsible for what people make with it

New Foobar GUI

Reply #46
v 0.2 Available

Neo: You get caught using that...

Choi: Yeah, I know. This never happened. You don't exist.


First pass of skinning support.  See foo_wsgui.ski (text file so any text editor).  Right now you must only use this file as the component is hard coded to look for it.  Eventually, it will be settable and you'll have 1 .ski file per skin.  ALso, note the format of the foo_wsgui.bmp file for the skin layout.  You can use PNG, BMP, GIF, JPG for the graphic file.

You can use foo_wsgui.ski *hopefully* to completely customize the skin.  Change the background, button layout, size, leave buttons out, etc.
Change the title format.
Change the title font and size.
Change the title behavior - always on, on rollover, etc.
Much more.

The file is only read at startup so changes require foobar restart.

Trial and error unfortunately is the best approach at the moment - I tried to add decent comments in the skin file.

Other noteable changes.
Alt+Left button to drag window now - much easier.

I worked hard on this over the last 24 hours so I'll be looking for some sample skins later this weekend  I'd like to see one where the title display is always on which should be doable with the current .ski settings.

Still some missing features (fill colors, font colors, font styles, etc.) and I will get to the preferences menu support pretty soon.  But you can do a lot with the .ski file in the meantime.  Also, the .ski format will evolve so don't be too mad if things change in upcoming versions that break the skins you make with this version.  I'll do my best to avoid that.

Enjoy.

New Foobar GUI

Reply #47
Cool, I'll try to play with it a little.

edit : errr... can I change font color and background color for the title display ?

New Foobar GUI

Reply #48
Quote
edit : errr... can I change font color and background color for the title display ?


Darn, you picked the one thing you can't do yet.  Did you try changing the size, layout, or graphics?

I didn't do the color setting yet because I am still deciding how I want to define color information in the .ski file.

Options are, for example

int backcolor 12222 // Decimal value of the ARGB

argb backcolor 255,0,0,0  // A,R,G,B

int backcolor 0xFF000000 // ARGB in hex

I only have support for the first format but I think that is the least user friendly.  I guess I could add it that way and try to add the other two to my .ski file parser later.  That way you could at least figure out the decimal value of your color choice and put it in.

Any other ideas or suggestions?

New Foobar GUI

Reply #49
-foobar2000 Basic Skin (preview)

EDIT: Updated. See next post.

Good work, danZ.