I'd like a delay for hiding it

Doesn't dbexplorere panel also have multiple views? They're just all simultaneously visible as nodes in the tree, rather than having to switch between them one at a time. It seems to me that albumlist requires extra mouse-clicks or keyboard commands to switch between views. I guess I don't understand why people would find that preferable. I know that there are some config options in albumlist preferences that don't exist in dbexplorer preferences, but other than that, is albumlist more configurable when it comes to creating views?

Rob

To me, the album list panel is just perfect. I like the fact that it is one view at a time, and that other views are in the context menu, not in a dropdown list (unnecessary clutter IMHO).

The main reason I'm so happy with it is that I have a fairly large database. That means that generating all views at once is not an option, as it takes too long. At the same time I still want to be able to have access to more than one view.

So, I couldn't ask for more really.

Ok, I'll make them both configurable then.


I meant having multiple hierarchies in the same window in dbexplorer, whilst you can only view one at a time in in album list.

Someone may prefer the latter because it is faster, and maybe the album list panel is faster in general. Someone else also said the album list panel supports multiple fields of the same name (e.g. multiple ARTIST fields) whilst dbexplorer doesn't. Album list also has drag & drop and the other options from album list 2.0, as you noted.

Yeah, something like that, but with playlist view implemented as regular foobar ui plugin (ui_standard, ui_columns, etc...) and loaded into the subwindow of genereal plugin for panels and sidebars. This way any ui plugin could have panels functionality.

I'll have a look at the revised API later. As for my list of problems, I haven't found solutions for all of them, but I'll post what I have after getting some sleep. I also tried to get familiar with the API by implementing a simple ui_extension_host, which took some time (I still haven't added a ui_extension implementation to foo_history though ).

Hmmm. I guess I don't consider having any view quickly selectable with a single mouse-click to be unnecessary clutter. I've been playing around with dbexplorer panel for only a couple of days and have already created about 15 different views and I have ideas for quite a few more. I imagine that having to right-click to select from a long list of views is going to become rather unwieldy. Also, with so many views, it's kind of hard to tell which view is currently showing in albumlist panel.



Regarding speed issues when generating all views at once, I wasn't aware that was a problem with dbexplorer panel as I haven't added most of my music to the database yet.



I had no idea that was possible with albumlist. It's a cool feature, but it only seems to work correctly when using the by artist view. In all the other views the artist name shows as artist1, artist2. Maybe someone knows if the other views can be made to work correctly.

Anyway, those are just my thoughts. Hopefully someone who is capable will be interested in making a plugin that combines the best features of both dbexplorer panel and albumlist panel and with enough config options to keep (mostly) everyone happy.

Thanks, Rob

For the history panel, could you make a track appear there only when it has been played for some time, like 30 seconds? I often just click next a lot of times to get to a part of my playlist I want (I have often no idea what I want but then I stop clicking when I find something I do).
This way te history panel would be far more usefull for me (maybe you can make the play time configurable?).

Another panel suggestion: can you add a 50 most played option in the database explorer tab? Maybe different ones under "by album", or "by artist" etc.

Does anyone else have the problem of the albumlist panel's scrollbar not resizing with the window? The bottom of the scrollbar is there when I maximize foobar, but it's hidden otherwise :/

Whoa... I was thinking about this only a couple of hours ago. Good idea, but this would need to be implemented in foo_history, since that's where the history panel gets the information it needs. I'll probably have a look at the foo_history source later this week and see if I can add it in.

As promised, here's a list of things I'd like to see changed.

Problems

1) I find it a little irritating that the host can "invade" a panels context menu. I have my context menu configured so that the most commonly used entries are located at the top, where they can be easily reached. Now in a panel, the host can insert commands. In the current implementation, a whole six lines are added at the top. Now in most cases, I don't want to close the playlist switcher, when I rightclick an entry in it. (Well, in alpha 3 another item is at the top, but I think you see my point.) Now what's worse, this behaviour isn't consistent: In the database explorer panel, when I click on a tree element, I get a context menu with entries only from the panel. When I click on the background in the same panel, I get a menu with only host-provided commands.

2) Having a toolbar panel - like playback buttons or visualisation - in the sidebar may be nice, but I don't think that being able to put the playlist switcher or history panel into the toolbar serves a purpose. These panels usually aren't designed for such a limited height. Furthermore, I'd like to be able to toggle panels in the sidebar like it is already possible with panels in the toolbar (but this already links to my third point).

3) This one is about various issues with the API, pertaining (but not limited) to single-instance extensions. I had a vague feeling that something was missing right now, and after thinking about it for some time, I got to the conclusion that I want to be able to programmatically activate an instance of a given ui_extension, either an existing one or a new one. Just showing a specific ui_extension through a hotkey could be solved by the host providing an appropriate menu command. However that does not help in the case when the command needs to do more than just showing a window/panel (read: the "Search for same [em]X[/em]" kind of commands in foo_dbsearch).

4) Something I noticed just today: When rightclicking on a non-panel part of the Rebar control, the contextmenu includes the "Remove toobar" command, even though it does nothing when selected.


Proposed solutions

1) Distinguish sidebar extensions and toolbar extensions. Sidebar panels should have a titlebar with their name on it. Panel management commands are only shown in the contextmenu of this titlebar, some may be available as buttons (like "Close"). Sidebar extensions do all contextmenu handling in their client area themselves.

2) Already mentioned in the solution for 1): make sidebar and toolbar extensions distinguishable on API level. If a host wishes to open a toolbar extension in a sidebar or vice versa, it may do so. (Even if I still don't like the idea of having sidebar extensions in a toolbar...)

3) Add a method for showing an existing instance and one for adding a new instance of a ui_extension to the ui_extension_host interface. Also add methods for retrieving the identity, name and the status of the host, i.e. get_host_guid(), get_name(), and is_avalaible(). A host could be unavailable due to belonging to a currently inactive user interface component. It might be a good idea to split the methods that are only called from an owned ui_extension instance into a separate ui_extension_callback interface.

4) Should be obvious.


Other suggestions

• Remove get_[min|max]_[width|height] from ui_extension, use WM_GETMINMAXINFO instead. This should simplify porting existing dialog to the ui_extension API.
• Replace notify_[min|max]_[width|height]_change in ui_extension_host with a single method on_size_limit_changed, indicate changed value(s) with flags. (All four methods call the same check_size method in my experimental ui_extension_host implementation (see below)).
• Pass host pointer as ui_extension_host* (or ui_extension_callback*) in ui_extension::initialise().

foo_floater: Opens panels as always-on-top toolbox dialogs, dialogs can act as target of drag&drop operations. Use at your own risk. Delete it if it causes problems. Ugly, quickly hacked up source code available to dedicated individuals on request.


Finally a call to all the component developers out there: if you are planning to add panel support to your component(s) sooner or later, I would suggest that you go for the "sooner" option, if you can afford the time. Changing the ui_extension API will be much harder, when it has stabilized.
Thanks again to musicmusic for putting so much effort into this component; your work is greatly appreciated.

foosion

Foo_floater is great.

1. May you place submeny "Floating panels" not only in Components and also in tray menu.

2. My second suggestion: dock floating panel to main Foobar windows.

foosion, foo_floater is really nice, thanks

One thing though (which seems to bug everyone making plugins), is that when a floating panel is on negative coordinates (=multimonitor system) the context-menu is not shown on the correct place.

edit: It also seems to give some metadb_leaks.

What would the string be to add "by Rating" to either the Album List Panel or the Database Explorer?

Thanks!

Nevermind! I've figured it out!

[quote=Killmaster,Sep 6 2004, 10:42 PM]Does anyone else have the problem of the albumlist panel's scrollbar not resizing with the window? The bottom of the scrollbar is there when I maximize foobar, but it's hidden otherwise :/

[/quote]
Not sure exactly what you mean, but its working fine here. What OS are you using?

[quote=foosion,Sep 7 2004, 02:00 AM]As promised, here's a list of things I'd like to see changed.

Problems

1) I find it a little irritating that the host can "invade" a panels context menu. I have my context menu configured so that the most commonly used entries are located at the top, where they can be easily reached. Now in a panel, the host can insert commands. In the current implementation, a whole six lines are added at the top. Now in most cases, I don't want to close the playlist switcher, when I rightclick an entry in it. (Well, in alpha 3 another item is at the top, but I think you see my point.)

1) Distinguish sidebar extensions and toolbar extensions. Sidebar panels should have a titlebar with their name on it. Panel management commands are only shown in the contextmenu of this titlebar, some may be available as buttons (like "Close"). Sidebar extensions do all contextmenu handling in their client area themselves
[/quote]
I didnt really intend on requiring panels to let the host insert its items.

Anyhow, are you infering that the host (i.e. sidebar) should draw these titlebars? Certainly, this would clean up the context menu which is obscenely bloated.

As for distinguish panels/toolbars, it isn't always possible (e.g. what would the vis come under)? I don't think its necessary for this solution anyway, any such panels can handle their own WM_CONTEXTMENU messages as necessary, and showing titlebars can be optional for each panel, maybe.

[quote=foosion,Sep 7 2004, 02:00 AM]Now what's worse, this behaviour isn't consistent: In the database explorer panel, when I click on a tree element, I get a context menu with entries only from the panel. When I click on the background in the same panel, I get a menu with only host-provided commands.[/quote]You must have written that sometime ago, certainly is not the current behaviour.

[quote=foosion,Sep 7 2004, 02:00 AM]2) Having a toolbar panel - like playback buttons or visualisation - in the sidebar may be nice, but I don't think that being able to put the playlist switcher or history panel into the toolbar serves a purpose. These panels usually aren't designed for such a limited height.

2) Already mentioned in the solution for 1): make sidebar and toolbar extensions distinguishable on API level. If a host wishes to open a toolbar extension in a sidebar or vice versa, it may do so. (Even if I still don't like the idea of having sidebar extensions in a toolbar...)[/quote]
I think adding a function to the ui_extension class like this is easier than attempting to differentiate them.

Like maybe bool get_limited_size_supported(unsigned orientation)

If orientation is veritcal, its if it supports limited width (im thinking vertical rebar or something), if orientation is horizontal, its if it supports limited height. i think its better than inferring it from whether they are intended for the toolbars or sidebar. Unless you can see a reason to just categorise them instead?

[quote=foosion,Sep 7 2004, 02:00 AM]Furthermore, I'd like to be able to toggle panels in the sidebar like it is already possible with panels in the toolbar (but this already links to my third point).[/quote]
I would agree, but it does also remove the ability to have e.g. two album list panels, with two different views. Not that I do that.. Actually it would simplify things, as you dont have to right click on a specific panel to remove it, so I will probably change it.

[quote=foosion,Sep 7 2004, 02:00 AM]3) This one is about various issues with the API, pertaining (but not limited) to single-instance extensions. I had a vague feeling that something was missing right now, and after thinking about it for some time, I got to the conclusion that I want to be able to programmatically activate an instance of a given ui_extension, either an existing one or a new one. Just showing a specific ui_extension through a hotkey could be solved by the host providing an appropriate menu command. However that does not help in the case when the command needs to do more than just showing a window/panel (read: the "Search for same [em]X[/em]" kind of commands in foo_dbsearch).

3) Add a method for showing an existing instance and one for adding a new instance of a ui_extension to the ui_extension_host interface. Also add methods for retrieving the identity, name and the status of the host, i.e. get_host_guid(), get_name(), and is_avalaible(). A host could be unavailable due to belonging to a currently inactive user interface component. [/quote]
Im not sure I follow you exactly; you want to be able to insert panels yourself into a host, correct? Including idx to insert at, and height/width?

I certainly see how it would be useful. If you want control over which index to insert it at, it would require more interfaces to be exposed in the ui_extension_host api though (get_count() for a start).

[quote=foosion,Sep 7 2004, 02:00 AM]It might be a good idea to split the methods that are only called from an owned ui_extension instance into a separate ui_extension_callback interface.[/quote]It would look cleaner probably, but then a ui_extension may want to pull info from the ui_extension_host interface, in which case separating them would just complicate things.

[quote=foosion,Sep 7 2004, 02:00 AM]4) Something I noticed just today: When rightclicking on a non-panel part of the Rebar control, the contextmenu includes the "Remove toobar" command, even though it does nothing when selected.[/quote]Thanks, I knew I'd seen that, but couldnt work out how to make it happen

[quote=foosion,Sep 7 2004, 02:00 AM]Other suggestions

• Remove get_[min|max]_[width|height] from ui_extension, use WM_GETMINMAXINFO instead. This should simplify porting existing dialog to the ui_extension API.
  
  
• Replace notify_[min|max]_[width|height]_change in ui_extension_host with a single method on_size_limit_changed, indicate changed value(s) with flags. (All four methods call the same check_size method in my experimental ui_extension_host implementation (see below)).
  
  
• Pass host pointer as ui_extension_host* (or ui_extension_callback*) in ui_extension::initialise().

[/quote]
Yes, that's all fine. I wanted to combine all that min max stuff anyway.

[quote=foosion,Sep 7 2004, 02:00 AM]foo_floater: Opens panels as always-on-top toolbox dialogs, dialogs can act as target of drag&drop operations. Use at your own risk. Delete it if it causes problems. Ugly, quickly hacked up source code available to dedicated individuals on request.[/quote]
Interesting

[quote=foosion,Sep 7 2004, 02:00 AM]Thanks again to musicmusic for putting so much effort into this component; your work is greatly appreciated. [/quote]Your welcome

Thank you for taking the time to input on this as well, its appreciated. I agree with most of it, so all that's left it to implement it, I guess.

As a sidenote: most of the popup dialogs in foobar repaint multiple times/unnecessarily when resized, causing much flickering, because they don't have the WS_CLIPCHILDREN style set. Foo_history and foo_dbsearch included, the former of which setting it kills all flickering (except for the problem I mention below). If you did make history/dbsearch support panels, it would be nice if you could change this to reduce flickering in teh main window, unless there is a reason you don't set this style? (I know it doesnt work properly with group boxes)

Wrong topic, but I also noticed a wierd bug in the foo_history ui; you can see a horizontal scrollbar showing when you resize it narrower.

[quote=anza,Sep 7 2004, 03:56 PM]edit: It also seems to give some metadb_leaks.

[/quote]
foosion: I think your not destroying the windows using ui_extension::destroy_window() or missing a service_release() somewhere.

problems with albumlist panel :

1) keyboard shortcuts (enter = send to playlist, shift+enter = add to playlist...) not work

2)left button double click action = send to playlist, add to playlist, send to new playlist" not work with titles ( middle button work )

3) "send to playlist" is unchecked , expand tree with direction arrows or find with letter send selection to playlist...

doctor, disease is engraves?

Yes, the goal is to have a clean separation between host and extension context menus plus an indication what the extension is. (Try adding both Album list and and Database Explorer to the sidebar to see what I mean.)

Another reason why sidebar extensions should handle WM_CONTEXTMENU themselves, is that MSDN recommends to show the context menu at the position of the active item, and the host does not know, what and where that active item is.


Extensions such as the vis would have to indicate that they can be used as both (sidebar and toobar). If you add a sidebar-style extension that handles WM_CONTEXTMENU itself to a toolbar, there will be little space left where the user can click to show the host's context menu. For me, a toolbar has limited height and contains relatively simple controls, so having a history/album list/... panel in a toolbar seems strange to me. On the other hand, I expect a toolbar-style extension with a WM_CONTEXTMENU handler to be quite uncommon. It's because of these different characteristics that I wish to tell toolbar and sidebar extensions apart. Perhaps it would be enough to have flags for different characteristics or groups thereof.


You are right, I have written that post over several days. Either I was hallucinating or I simply forgot to re-check/update the component before posting.


No, i wouldn't need to specify the exact location where the panel is added. The idea was that after investing effort to make a component into a ui_extension, I wouldn't have to resort to create a "normal" window. Given that I didn't (and still don't) know how complex it is to create a hybrid dialog that can be used as ui_extension and native dialog, I wanted to be able to show an extension on demand. Another idea behind foo_floater was that it could be used as a fallback host.


True.


The most important reason must be my ignorance. I'll try your suggestion.


I'll respond to that in the appropriate topic in due time.

i think it would be cool if the dbexplorer in foo columnsui remembered your last position when you open foobar.

example. if you exited foobar and your dbexplorer was on mozart, it will open the next time on mozart.

Is it possible to exclude certain directories in the album list panel? I don't like having my album list clogged up with misc mp3s from various directories, and would like to keep these from being shown.

Albumlist gets its data from fb2k's database. To limit the database to certain directories: Preference > Database > Restrict directories to

I tried that, unfortunately it gives no option to exclude directories. There are 2 directories out of 295 that I don't want in my database, which means I'd have to a.) move the 293 other directories into a seperate directory, which I don't want to do or b.) Manually add 293 directories, which I also don't want to do :/

You could use an app like jv16 Powertools to export a text list of the directories, remove the two you don't want, then copy and paste it into foobar's prefs. jv16 is shareware, though. Maybe someone knows a freeware app that can do this.

It's possible from the command prompt as well, I'm sure, but I couldn't say how to do it.

edit: last freeware version of jv16 is available here:

http://www.321download.com/LastFreeware/index.html

dir /ad /s /b > dirs.txt

Hi,

I seems to having issues getting "Enter" key to work as expected on the albumlist panel (Send to playlist, and play)

Anything i'm doing wrong?

You can also make these direcories hidden (check "hidden" property in explorer). They will not be added to the database then.

Many bugs...

Try version 0.1.1

You mean by keyboard right? Even if the current implementation was to remain, that would hardly be difficult to solve (pass the POINT pt parameter as a pointer or reference..)

Ok sounds fine.

Maybe, it doesn't prove a problem on the windows taskbar though..

Yes, I agree to categorise them.

Okay. I thought you'd either want it user configurable as to where it appears, or make it open where it last was next time you opened it.

I don't believe it should be that complicated with the revised api. I was going to try with an existing component to find out/see if any problems arise.

I updated the (proposed) revised api I posted, tell me if i missed anything etc.


See above, and try version 0.1.1.

albumlist 0.1.1 Keyboard shortcuts is still not working.

Strange behaviour noticed:
With Process keyboard shortcuts checked, i cant quickselect an item, aka find "aimee mann" by start typing fast "a","i"
Without it i can, other then that, i can't understand what other behaviour this checkbox triggers...

AFAIK "Process keyboard shortcuts" means, to handle keypresses by default foobar2000 keyboard shortcut handler. It means, that keypresses dont affect album plugin.

Well, i can't see how enabling this prevents the treeview control from doing the normal speed search (typing "s" to go to first entry with "s")
in any way, in 0.1.1 thats what happends here...

any chance that the sidebar does not have to be the side bar?

so it can go where implied.

Because also single letters can be assigned as shurtcuts, for example in standard foobar2000 install keys Z, X, C and V are assigned, to accordingly "Stop", "Pla", "Pause" and "Next".

Thats OK, however if they are not shotcuts, they should be still used for speed search, just like the normal albumlist does.

Relaying a feature request, how about optional configurable vertical scrolling sensitivity? Simply scaling the scrolling units relative to the playlist size should be enough, but making it optional, and making the scroll unit configurable would be better.

To get more advanced, it might also be a good idea to either configure different effects for different playlist size ranges, or perhaps more simply, minimum and maximum lines per unit limits.

(Now, wouldn't it be much simpler if mouse software just offered different presets for different applications? Or if this sort of feature could be a part of the operating system or window manager?)

Nuke the database, remove the restricted folders, drag&drop the folders you need to a playlist. Refresh the albumlist. One downside will be that whenever you add new files, they will be added to the database.

Thanks musicmusic for all your work, this is getting better and better every time you post a new version

About your albumlist panel, there something I will like to request if you find it useful.

Could it be possible to have the option 'Adds items only when double-clicked instead of when just focused on' like in the modified DB Explorer dll from Rexy?
http://www.hydrogenaudio.org/forums/index....showtopic=26937

And something I've found when trying the albumlist panel v0.1.1. is that when I set it like this: 'Double-click action: Add to playlist', the tracks are added twice when I double-click. Also, tracks replace the content of the playlist instead of just adding them. That's also why the option 'Adds items only when double-clicked instead of when just focused on' would make it easier

Good work. Really appreciated.

some navigation buttons questions:

1. anyone did a good set that would also demonstrate all the posibilities?
2. how do i define 'mouse over' or 'on click' or 'active stage' images?
3. whats the default resolution? (107 x 14?)
3.2. can i change the default pixel resolution?

tia.

1) screenshots: 1 2
2) you can have only mouse over state over normal state - bitmap then has to have twice the width - first half has normal state, second mouse over state. see here (there are others with numbers 01 to 09).
3) default? that's not really important, i guess height 24, so 7*24 width for normal state only bitmap
3.2) of course, it's only up to you

it's a bit limited, so here goes my request ...

musicmusic:
i know it's just desing stuff etc, not really important, but could we have not only mouse over, but even 'down' state in bitmaps? you could detect number of states from width / height / 7. and another request ... please, give us checkbox to disable 'button background' rendering (i.e. no frame), so we could provide our own 'active' states for buttons and have no additional graphics being renderen in the background (based on theme etc.). i'm not sure whether that's achiavable in win32 without custom code.

It is working here Maybe its related to columns ui or something then, I will look into it again later..


At some point yes. I am not sure when though.

Maybe your albumlist is more special than mine, but mine certainly does not process any non-global keyboard shortcuts.

Keyboard shortcuts are processed in a different place (WM_KEYDOWN) than where the tree view control proccesses key presses for its jump-to-letter stuff (WM_CHAR), and so the sanest thing to me seemed to disable the other if one was selected (as they may conflict as filon noted).

I may be able to get them both to work together, I will look into it.
Are you referring to clicking on the up/down arrows on the scrollbar, or something else? (Selecting/reordering items, mouse wheel). Or even all of them?

Thats a lot of customisation for just scrolling..

Less crazy, yes.

So you want basically the option(s) "[scroll p lines per unit] OR [scroll one line for every x playlist entries (of total playlist entries), with a minimum of y lines and a maximum of z lines]"? Or something more sophisticated than that? I don't really use the up/down scrollbar arrows, so I dont really know what would work best..

Anyhow I will add it to my todo list, though I dont know when/if it will get implemented right know.

I will check those things later. Did you disable "Auto-send to <playlist>" though?


Toolbar control doesn't support different on button down images natively (Im fairly sure it doesnt), so its more complicated. The other thing that bugs me is that if customisable buttons is implemented I dont know how it would co-exist with the customisable button bitmaps, though thats another story..

I can disable the toolbar control from drawing the button edge & background though, and I seem to remember being to adjust the padding so that your bitmap covers the whole button. I will check if that works out ok, and add it to my todo list.

any updates for the history panel?
What i reaaly want is to be able to customize the colors and fonts...
OH! and tonight i managed to break it somehow. I only downloaded the latest "special" installer (i do it pretty much every week) and also updated the panel plugins... After doing this the history items don't appear in the list anymore... it's just one solid white panel
Thank you for the plugins

The foo_history_panel gets its info from foo_history, so make sure you have that as well.

QUOTE(kode54 @ Sep 11 2004, 09:41 AM)
Relaying a feature request, how about optional configurable vertical scrolling sensitivity? Simply scaling the scrolling units relative to the playlist size should be enough, but making it optional, and making the scroll unit configurable would be better.
Are you referring to clicking on the up/down arrows on the scrollbar, or something else? (Selecting/reordering items, mouse wheel). Or even all of them?

He's refering to if there is any way to change how many tracks is moved for every scroll using the mouse scroller. So far it seems that you can only scrow 3 tracks for every scroll click(scroll up or down). It would be great if it can scroll more tracks for every scrool click when there is a large database of tracks on the playlist (kinda like how winamp does it)

foo_history works great.... but the history panel is blank
I also tested on a clean foobar install but that didn't work either...
Weird...

No Now it works But the thing is that I prefer to have a 'pre-assigned' playlist to add all my tracks via the albumlist panel. Anyway: Thanks a lot!

Hi musicmusic!

I know this has already been requested (see above), but it's a REAL neat feature, that I hope to see soon in ColumnsUI. Maybe you also have seen the actual thread on the main-page (HERE) (this was the hang-up why I'm posting it here again).

Thanks for your great component! Love it!
Moon

tnx mazy, and those are some really cool buttons.

3. how is that not important? (i dont want the app to scale my bitmaps), or can i force the app to use my own resolution for the button part?

- so there are (only) two states right? (onmouseover and onmouseout)

Well, not so weird at all. Case's special installer already contains the release cancidate of foo_history 0.8. While this version improves handling of moved and deleted files, it is incompatible with foo_uie_explorer. Until foo_history 0.8 is complete (it will presumably come with support for a history panel), you can use foo_history 0.7.2.

the gui would not scale your bitmap, but change dimensions of the toolbar's buttons accordingly to the height of your bitmap (adding some space around etc.). atm, the bitmap can only have normal state (or onmouseout, if you wish) and, optionally, mouse over state (you can configure that in columns ui's preferences, last tab 'other', checkbox 'bitmap includes mouseover images').

foosion said he would probably support a history panel in foo_history itself, and so the component is more or less dead.

Mouse wheel then. I scroll using the system setting, which is/was 3 lines by default yes. I have only a slow=>fast slider in mouse properties, presumeably to support the newer "smooth" mouse wheels (without notches), such as mine..

I will try and get it implemented for the final version of 0.1.2.


No I hadn't seen that thread, but yes I did try and implement it ages ago about when I said that and I ran into some problems. Though I think I had solutions for them but I never got around to trying them.

So i will revisit it at some point, not sure when though, depends on how other things go.

Since it's a spare time project of yours, I'm not the one to tell you what to do. But 'Thank you' anyway for trying...


Greetz.
Moon

Another request for the albumlist panel....
Could it be possible to implement the 'Start playback when sending to playback' that's in the original album list?

Never-ending thanks for this great component