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: foo_looks 2.0 (RC1) (Read 287441 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foo_looks 2.0 (RC1)

Reply #50 –
Quote
- you can make any part of the look appear/move/disappear based on a condition, or a button
for example, you could write a script that swaps the position of the track info & buttons depending on whether the look is docked on the top, or the bottom of the desktop

I'd love to know about this - I assume this means I can tell it that if I change layouts that I want it to keep the top right point the same if I'm in the top right part of the screen? (e.g. put the default look into Cover Art Layout, move it to just left of the minimise button and then change to the Standard Layout. You'll know what I want to change then!)

foo_looks 2.0 (RC1)

Reply #51 –
test out the progress bar on this new skin (in development)




P.S. did you notice my songtime is gently embossed - a nice little trick

the skin is far from complete.. i just wanted to show the dragbar

i'll let you know as i make more progress - i'm planning to have some really innovative features on this skin... watch this space

foo_looks 2.0 (RC1)

Reply #52 –
Quote
i'll let you know as i make more progress - i'm planning to have some really innovative features on this skin... watch this space

watching eagerly

foo_looks 2.0 (RC1)

Reply #53 –
tk32: I've noticed a bug in the progress bar code:

Code: [Select]
function onattach(this)
    minx = look_getX(this)
    maxx = look_getWidth(this)
end


I think that minx should be 0, I have a progress bar that is several pixels from left and if I use your code clicks are not properly recognozed, however if I set it to 0 it works just fine. Correct me if I'm wrong.

foo_looks 2.0 (RC1)

Reply #54 –
Quote
tk32: I've noticed a bug in the progress bar code:

Code: [Select]
function onattach(this)
    minx = look_getX(this)
    maxx = look_getWidth(this)
end


I think that minx should be 0, I have a progress bar that is several pixels from left and if I use your code clicks are not properly recognozed, however if I set it to 0 it works just fine. Correct me if I'm wrong.

thanks crazycoder, i'm sure you're right

i didn't think anybody would debug it

although i knew it wasn't in a fit state to re-use yet

would you mind if i played the 'tired card'   
it was 3:00am when i wrote it

when using an offset progress bar, it's easy to lose track of whether you are making absolute or relative calculations

it was just a quick hack on the slider script, and it needs a bit of tidying.
i'll also doublecheck it's totally generic.


but i'm glad it's working for you already.


i'll make the other improvements, and then put the slim & complete version on the resource pages when it's done


thanks for shaming me  - i'm happy to see there are other users already interested in the finer points of LUA scripts

foo_looks 2.0 (RC1)

Reply #55 –
Quote
tk32: I've noticed a bug in the progress bar code:

Code: [Select]
function onattach(this)
    minx = look_getX(this)
    maxx = look_getWidth(this)
end


I think that minx should be 0, I have a progress bar that is several pixels from left and if I use your code clicks are not properly recognozed, however if I set it to 0 it works just fine. Correct me if I'm wrong.

If the logic is based on the size of the sprite then minx should probably be look_getX(sprite) and maxx should be minx + look_getWidth(sprite).

Code: [Select]
function onattach(this)
    minx = look_getX(this)
    maxx = minx + look_getWidth(this)
end


EDIT/ BTW, nice use of borders and fills.

foo_looks 2.0 (RC1)

Reply #56 –
what about the functionality of the dragbar? do you like it?

foo_looks 2.0 (RC1)

Reply #57 –
Quote
Quote
Quote
2. [..]
I want you to attach a volume controller there like v1.10.
How is it?

Please tell me.

There is a volume control on all of the default skin layouts (it isn't obvious though!). If you look just above the album art, you will see a small empty square. If you click and drag this horizontally, you will find it is the volume control..

Hope that helps.

You can also use the mousewheel over the background to change the volume.

The volume is positioned the way it is now so it can be visible on all layouts w/o any additional scripting to reposition it.

OK.Thank you.
It carries out based on a default skin,
and when free, I think that will make a skin.

foo_looks 2.0 (RC1)

Reply #58 –
Quote
Quote

1. I am a Japanese.
A jacket art will not be displayed if Japanese
is contained in the folder name.

Fixed in RC2 which I'll post sometime today.

A jacket art will be displayed even
if Japanese is contained in the folder name.

Thanks! 

foo_looks 2.0 (RC1)

Reply #59 –
Quote
what about the functionality of the dragbar? do you like it?

It's great. Thank you =) I appreciate your work.

I hope some day there will be a generic dragbar in the common scripts that will have an option - to use a grip or to use your approach.

I've notived that making simple things requires a lot of code in foo_looks 2.0 if to compare with 1.0. Of course, it's because generic scripts for standard controls are not written yet. My very simple skin is now 700 lines of code, but it was about 100 lines in 1.0.

foo_looks 2.0 (RC1)

Reply #60 –
Quote
Quote
what about the functionality of the dragbar? do you like it?

It's great. Thank you =) I appreciate your work.

I hope some day there will be a generic dragbar in the common scripts that will have an option - to use a grip or to use your approach.

I've notived that making simple things requires a lot of code in foo_looks 2.0 if to compare with 1.0. Of course, it's because generic scripts for standard controls are not written yet. My very simple skin is now 700 lines of code, but it was about 100 lines in 1.0.

Right, as I stated, foo_looks 2.0 does less for you but gives you the power and flexibility to do more.  1.x was all about making it easy (thus the large, inefficient graphics layout, the built-in sliders, etc.)

Are you using any of the scripts from foo_look_common.ski?  Those are all intended to be generic and reuseable and to cover common things.  It is far from complete and tk32 and I are both intending to attempt to make as many basic scripts availale as possible so that a basic look can be constsructed by just defining some sprites, importing the common scripts, and attaching those as needed.

I'm even considering expanding the import to allow something like

import http://www.blah.com/commonscripts.ski and then we could host common scripts on the same site as the looks.

Expect 2.x to continue to improve and remember that in 2.0 I basically started over so its more like a first release then a 2.0 despite the name.
 

foo_looks 2.0 (RC1)

Reply #61 –
Quote
Right, as I stated, foo_looks 2.0 does less for you but gives you the power and flexibility to do more.  1.x was all about making it easy (thus the large, inefficient graphics layout, the built-in sliders, etc.)

Are you using any of the scripts from foo_look_common.ski?  Those are all intended to be generic and reuseable and to cover common things.  It is far from complete and tk32 and I are both intending to attempt to make as many basic scripts availale as possible so that a basic look can be constsructed by just defining some sprites, importing the common scripts, and attaching those as needed.

I'm even considering expanding the import to allow something like

import http://www.blah.com/commonscripts.ski and then we could host common scripts on the same site as the looks.

Expect 2.x to continue to improve and remember that in 2.0 I basically started over so its more like a first release then a 2.0 despite the name.

Sure, I understand and fully agree with you. Thanks for the input.

Yes, I'm using some common scripts, of course. I like the flexibility of 2.0. It's a good start. However I'm not a designer, I'm coder, I've created a simple look that suits me for 2.0, it took about an hour to create it. Actually, it's almost a port of foo_looks_mini from 1.0 with my custom changes.

At the moment I don't have enough time to play with it, but I'll certainly do so later.

The quick and dirty port is available here: http://amip.tools-for.net/config/dl.php?fi..._looks_comm.zip

Standard state:



Small bug report: I've noticed that when screensaver disables my look image is messed up, I think that it has to deal with the same thing described some posts above (problem when window is overlapped by another)

foo_looks 2.0 (RC1)

Reply #62 –
I've toyed around with foo_looks 2.0 and created this thing, which looks something like this (only the screenshot is not animated):


However, there is one thing worth mentioning: when this is loaded, the VM size of foobar increases by about 100kB every second. I noticed this when Windows told me that it had to increase the swap file. After I was aware of that, I tried the foo_looks_one skin. With that loaded the VM size increased by some kilobytes every now and then, mostly when something is animated.

The most important difference seems to be that my script makes heavy usage of functions that manipulate sprites (change location or image source position).

foo_looks 2.0 (RC1)

Reply #63 –
Quote
However, there is one thing worth mentioning: when this is loaded, the VM size of foobar increases by about 100kB every second. I noticed this when Windows told me that it had to increase the swap file. After I was aware of that, I tried the foo_looks_one skin. With that loaded the VM size increased by some kilobytes every now and then, mostly when something is animated.

I've noticed the same thing, I've left foobar for the night playing and in the morning it crashed because out of memory. I've just noticed in the process manager foobar takes about 70mb after a couple of hours of playing.

It is defnitely related to foo_looks, hope this will be fixed soon 

foo_looks 2.0 (RC1)

Reply #64 –
Quote
I've toyed around with foo_looks 2.0 and created this thing, which looks something like this (only the screenshot is not animated):


However, there is one thing worth mentioning: when this is loaded, the VM size of foobar increases by about 100kB every second. I noticed this when Windows told me that it had to increase the swap file. After I was aware of that, I tried the foo_looks_one skin. With that loaded the VM size increased by some kilobytes every now and then, mostly when something is animated.

The most important difference seems to be that my script makes heavy usage of functions that manipulate sprites (change location or image source position).

Yeah, good catch, I had a memory leak in look_setRect().

So are you going somewhere with your tilemap or just messing around - its a cool effect.  I was thinking I might script a space invaders game or something just to show the foo_look sprite manipulations, etc.

I know you've been doing a lot with lua so let me know if anything I'm doing seems odd or incorrect.

Look for RC3 in a day or so with the memory leak and a few other bugs fixed.

Edit/
BTW, FYI after looking at your .ski file just want to make sure you know you can do the following.

section tile_common
list fillcolor color.black
list statemap states.None
list rendermap int { render.Image }
bool visible false

sprite tile00
string include "tile_common"

sprite tile01
string include "tile_common"

and so on...

foo_looks 2.0 (RC1)

Reply #65 –
Quote
Yeah, good catch, I had a memory leak in look_setRect().

So are you going somewhere with your tilemap or just messing around - its a cool effect.  I was thinking I might script a space invaders game or something just to show the foo_look sprite manipulations, etc.

More like "just messing around". Coding a game will be a pain in the neck, unless you add the ability to dynamically create sprites - which would also simplify coding a resizable skin with a playlist.

foo_looks 2.0 (RC1)

Reply #66 –
v2.0 RC3 Available

Changes

1.  Fixed parser bug that prevented using table lookups such as x = foo in inline scripts
2.  Created new global - look_sprites - which is a table of all loaded sprites as defined in the .ski file -
ie.
{ sprite1, sprite2, etc }

This is useful if you want to perform an operation on all sprites or iterate all sprites.
3. Fixed NULL pointer dereference which was causing foo_tunes to crash at startup.  Tested succesfully with foo_tunes 0.0.4
4. Fixed memory leak in look_setRect() - thanks foosion for reporting
5. Moved "albumartDisplay" script to common import file
6. Added albumart slider to default look which will allow you to view all cover art matches.

foo_looks 2.0 (RC1)

Reply #67 –
DanZ,
very very nice... with your look v2 and Tunes, Foobar is finally getting there!!
           
(and your RC3 works a treat with Tunes running)
cheers and nice work,
Peter

foo_looks 2.0 (RC1)

Reply #68 –
just noticed it now, when I try to swap looks from the look components menu, foobar crashes; it does not happen if I use the component menu from the systray.

the slider for album art works great, but it would be nice hiding it in the cover look when the mouse is not on the look for example...

great work !

foo_looks 2.0 (RC1)

Reply #69 –
Quote
just noticed it now, when I try to swap looks from the look components menu, foobar crashes; it does not happen if I use the component menu from the systray.

the slider for album art works great, but it would be nice hiding it in the cover look when the mouse is not on the look for example...

great work !

I can't reproduce this.  What look are you swapping from and to?

Also, both menu handlers (compenent menu and systray) run in to the same function internally so I'm surprised it only happens from one approach.

foo_looks 2.0 (RC1)

Reply #70 –
from your look to any of tk32' or from tk32' last one (tk32-new_skin_project) to one of yours.

here is the crash log.(foobar 7.7a, winxp sp1)

EDIT: removed crash log.

foo_looks 2.0 (RC1)

Reply #71 –
that's very strange


i switch from my looks to danZ' looks all the time.. [span style='font-size:8pt;line-height:100%'](because it's the quickest way of unlocking the graphics file when you need to overwrite it)[/span]


and i can't recreate this either

it could possibly be a clash with another plugin, since for my 'look-editing' instance of fb2k i only have a minimal install

core (0.7.7) + foo_looks (2.0 RC3)


i'll try testing some more

foo_looks 2.0 (RC1)

Reply #72 –
I'm getting this crashing also. I have a number of different plugins installed and I haven't yet tried removing any to see if it is a bad interaction..(will do this now)

Oh the first part of my Stack dump involves lua_close (not lua_error as above)

foo_looks 2.0 (RC1)

Reply #73 –
Ok I just removed all but
foo_console
foo_input_std
foo_looks
foo_output_std
foo_ui_std

and I can get this to happen by swapping between any two looks from the components menu in the looks (not the foobar one or the tasktray one. It even happens when I set the default foo_looks.ski as both primary and secondary look...

HTH

foo_looks 2.0 (RC1)

Reply #74 –
thanks for your efforts teetee

now we just have to wait for danZ to visit the topic and give us some insight


btw, anyone got any foo_looks projects on the go??


---

i added some basic playlist support to my new project