I gave this a try ago a few days ago, since I got curious after Case included it in his special installer and I must say I got hooked quite soon. honestly, damn nice work musicmusic. Should have tried this earlier . Never really got interested because I never had the need for by columns sorting, but see nowe tht it has quite a few nice other features. Great work with the titleformattign window and syntax btw.

And of course I can't keep myself from a few small feature requests. Admittedly I haven't followed this thread from the beginning so my apologies if this has already been asked for.

One of the other things I also gave a shot lately os foo_scroll. So I was wondering if you could maybe include that kind of functionality directly into columns ui. Kind of something like an advanced follow cursor. Basicallyl I either have scroll and follow cursor enabled, or both disabled. Haveing the abilty to do both with just one menu tickbox would be great.

Also quite like the titleformatting benchmark and was wondering if it would be possible to include an option to benchmark the entire string at once, instead of just the individual sections. Would be nice.

Also it woudl be quite nice if the selected item and frame color could be defined for the playlist side bar.

Hmh, now I am sure there is something else that I forgot now, but that is already more then enough anyway

Anyway, thanks once more for this nice compnent and keep up the good work.

i agree. the thing is, yes i think foo_scroll's features would be a nice addition to foo_ui_columns, but i even think they (or some of them) should be included in fb2k core. just because someone doesn't want the playing order to follow their mouse doesn't mean they don't want fb to show whichever song is playing!

and definitely, thanks a lot for this plugin!

Just found a weird bug:
I was just merging my different strings to one with different color schemes, which would be changeable through the global variables. When I select a color scheme (by changing the value of %_color_scheme% to another) and press apply everything works, but when I press only the close button (so I haven't applied the change) the bug happens. The tracks that were visible stay formatted with the old color, while all the others change. Hope you understand

Thanks



Sorry, you lost me there..



I see no reason for this to be implemented in the UI. I don't even think "playback follows cursor" could be implemented as it is in "follow cursor" outside of teh playlist engine (in the CORE).

I dont know exactly what you mean, sorry. Currently it just tests the string displayed on the first 10 tracks on the playlist.

It does not reflect actual performance, for example global variables are not made available when formatting. I doubt that is what you meant anyway, please elaborate.

Yes, this was planned. The List Box control supports no such thing itself, but I could draw it myself, actually the code for that is already there just commentted out. So maybe i will just uncomment it and implement the colours options for the next version.


Thanks, should have already been fixed for the next version

any date for foo_dbexplorer? if you could import this so that it displays in foobar, it would be great

also how can i list the songs like 1... then 2...

My opinion is autosort future - playlist sort according columns sort rules in real time.
Example: I use playcount plugin and it change next tags PLAY_DATE and PLAY_TIME any time as song is playing. If I use next custom sort
$num(%PLAY_DATE%,6)$num(%PLAY_TIME%,6)
I can sort my playlist by last playing time, but I must do it manually, not automatically.

Just meant I really like the way that you implemented globals into the formatting. Interesting approach with setting user defined strings to special info fields.



Ok, makes sense. Was just a thought



I simply meant that it would be nice to have an option to test the entire formatting string, rather then just the string displayed. Ie, benchmark all trings, not just the one displayed and add them all up.



Nice.


Oh yeah, one thing I forgot before. Maybe a feature to sort all playlists in sidebar or tabs alphabetically would be nice. Should be possible with current API and might make browsing playlists a bit simpler in case you have many.

Is it possible to turn off the capitalization for artist and title?

In your column coding it probably says:

or similar. Change this to:


Needs to be done in both Artist, and Title columns

Steve

This, in theory, sounds like an idea. But I can see it being more problematic than its worth.

For example: You have it set up to auto-sort as you said, so when those tags are updated, in the currently playing file, it is moved to the bottom of the playlist, and so (under default playback) foobar will then just stop playing (or it will actually repeat that track, but that's a bug).

Steve

I really like this too. I have just started using this UI on a regular basis, and I have a question/request regarding these global variables. It seems to me that a global variable is only accessible outside the global section itself. In other words I can't make one global variable depend on another defined earlier. My current workaround is to use $puts() and $get() first to make these kind of dependencies possible, and "translate" them into global variables at the end of the globals section. IMHO this makes the code inefficient and less readable. Maybe this is because I haven't really got the hang of it yet, but it seemes to be the case.

Another thing I'm wondering is whether a column that is not shown/enabled is processed or not. Just want to make sure they are not, before I add columns that I won't use/show on a regular basis.


I second this. I think it would be really helpful when trying to optimize the string(s). Currently I just do things I think will optimize it, but I don't have any proof that it really does. So, if it's possible to add something like this, I would appreciate it if you did.

Anyway, thanks for making this great UI musicmusic. It has for sure taken me a while to get used to it, but thanks to picmixer's formatting and the general progress of the plugin I finally moved on from the default UI.

i thought about porting my formatting strings over to ui_columns and enhance them. In the past i waited for color-codes in global strings to be supported (maybe via a new foobar-version), because a while back i converted all of my strings including all color-themes from hex to decimal. So, for the color-config to work in the global string i would need to revert back to my old method(which basically meant $puts(artist-color,00FF00) and then later making a color string of that value).

Anyways, i also decided that i would be willing to do that. But now i stumbled over another problem: i modify the colors which the user did set afterwards in some cases, like i.e. blending them against the background, etc.
However, without color-codes in the global string, i would need to do those calculations >multiple times< for each column which i want to display. Thats horribly inefficient.

So, again the question - did 0.8.2 change anything to the color-code problem in global strings? Or is there absolutely no reasonable hack possible to get it to work?

I would really like to start porting my strings over to ui_columns and improve them, because ui_columns allows some great possibilities on what i could do with them. I like this alternate gui - but doing the above mentioned would be quite inefficient to do without color-codes in the global string.

- Lyx

I see. It was kode's idea anyway.



I think I see what you are getting at, you want to compare everything at once to find the slowest part, right? And a total afterwards? Ok then I will do somehting like that probably after 0.1.1.



True, but it could equally be implemented directly in the playlist switcher instead so it applies the same everywhere, or a separate component that adds (manual) sorting of the playlists (i.e. through a menu item). I don't think automatically sorted playlists would be particularly useful.


Yes well its either that or preprocess the string to break it into each variable/value pair, which will break functions across variables, i.e. $puts() $if() etc., like the masstagger renamer and \ and / characters. Actually you could still use $char(7) (instead of the actual character, i.e. the square) to overcome some of those problems, but then it wouldnt be caught in the preprocessing and would not be available until some next random point in the script. Preprocessing the string may also be slower and it will also probably be a complete mess, as it probably sounds.. It would also allow you to declare global variables to use in your globals only and not the columns etc. which is silly/inefficient.

I think $puts() and $get() is your best solution, it shouldnt be inefficient. You could just keep all your $put() stuff at the beginning to make things clearer to yourself if you want.

No, of course not :B. Unless by shown you meant with width 0; then yes, they are. I could probably change that, but I dont see why anyone would size them to 0 pixels instead of disabling them instead (from the header context menu, or from preferences).

Your welcome


What calculations are you doing? I can only think of things such as $transition() which are beyond your control and will insert colour codes everywhere.

Anyway, no they dont work. the only half-workaround is for me to remove all char 3s. That still would not help you though as you cant reinsert them when you cant currently anyway. I could use a different/alternate char I suppose since I am processing the colour codes myself, i.e. $char(4) , 5 or something. I dont think anything in the 1 to 6 range will conflict with anything. That still wouldn't help with $transition() much though, sure you could do $replace() or something but that would probably be slow, and silly.

nope, i wasn't talking about $transition but instead $blend()

Also, there are multiple color-themes.... at the end of the global string, there would simply be an $if() check to see which color-theme was set in the config-part of the global string - and after that lots of $puts(artist-color,color-string-here) would follow.

Without color-codes in the global string, i would need to "build" those variables inside of each column, instead of just "building the selected color-theme" one time in the global-string and then using those variables in each column. Inside of this "building the colour-theme" $blend() is also used sometimes to calculate some colour-codes.

So, what would help me basically is storying vars in the global-string which contain color-codes - sometimes calculated via $blend().

example:


Only the result of artist_col2 and artist_color is needed.

edit: extended the example

I see. If I was thinking correctly before, I would have said that a solution that would work properly is for me to change all char 3s from the output of the global string to char 6s or something, and then process them as colour codes too (or even map 6s back to 3s).

That would work fine I think but rather than having to resort to that I would rather there was a $extra() in foobar that does not have these checks (and doesnt truncate multiline strings too). Well whatever.

edit:

Also, you could implement this on your side if you really want.

Enclose you global string in $replace(<string>,$char(3),$char(6)) and then your column string in $replace(<string>,$char(6),$char(3))

Or, for $blend() you could just use $substr(<colour code>,2,7) and put the $char(3)s back in in your column string.

I don't have any suggestions or problems. I just wanted to say that foo_ui_columns is a great plug-in. I've been using it exclusively since the start of the year, and I've been very happy with it. Thanks for all the hard work, musicmusic! ;-)

well, i've got no problem waiting a little bit more, now that i already waited patiently for a long time, hoping something like that could happen.

Still, many thanks for this info - that way, i can already start some porting and then later - when it got implemented into ui_columns - remove the workaround again to make the code more readable(yes, i know that the "workaround" would still happen invisible in the background).

thanks :-)

I have a small feature request regarding the sidebar:
Opera (the web browser) has an ingenious way to toggle such a sidebar. Instead of moving the toggle area in and out with the sidebar itself, the toggle area is always located at the outer edge of the window. This makes it very easy to toggle as you don't have to aim your mouse pointer at that moving border (here located between sidebar and playlist) and double click it, but can just move it all the way to the left (or right) and click. Easily done without moving your eyes. This is of course only an advantage when the window is maximized, but I tend to have foobar maximized as I only have a 1024x768 screen resolution.

I know this might not seem like a big thing, and probably it isn't, but I like such small ingenious details

3 ideas:

- would it be possible to intergrate the windowtitle-, statusbar- & copystring-formatting into ui_columns(including access to global variables in both) ? That way, it could be a full replacement for the standard_gui + access to global-vars in the copy-string would allow some nice features

- is it possible to make the global-vars also available to other components in foobar? That way, for example a color-theme can also be applied to a foo_osd string

- if one could specify the general background color in the global-color-string as well, that would make color-theme-switching complete

imho, the global string of ui_columns would be a perfect place to centralize most string-configuration (i.e. if an ui_columns style has themes, then those themes can automatically be applied to the osd_string, etc.).

- Lyx

edit: removed one request - my fault - already implemeted

I look at the seekbar to follow progress of a track.
From across the room, I am unable to it clearly.
I would like to make it stand out by giving it a colour - I like blue.
I should be grateful if you would tell me how I can make my seekbar clearer.

hey, now i know why this thread has so many replies. this component is really good.

the only problem i'm having is that setting colours (and knowing which value adjusts what) is really hard. does anyone have an easier way to do this? sorry if this is covered, the thread is huge

well, i'm currently trying to port my strings to ui_columns - and one of the things which i'm trying to archieve is that all colors can be configured at a single place(a configuration-part in the global-string). Only problem is that i haven't yet found a way to set the main background-color via strings.

Go to Display > Title formatting, use the Change color button, copy the value you get, paste where you need it. Lots of clicks but uses less brain cells than learning hex values.

Temporary solution (or maybe a permanent one): using Kode54's On-Screen Display plug-in, set the code as:



Or something similar the syntax is in Foo's formatting help file.

Steve

Sorry Paranoia, but I cannot find:

Was it downloaded in my install or do I get it from another site. I could find only two kode54 plugins. Nothing for a display. Please show me the link.

here

Thank you so much upNorth, got the plugin.
Now where do I paste the code. Does it go in the format window for On-Screen Display under Components ??

I tried to understand what you are saying, but I don't. It doesn't sounds simple to implement.. If it is mouse gestures, you could try the gestures plugin and use the menu item to toggle the sidebar.

Maybe when Im sufficiently bored I will install (and probably uninstall) Opera and see what you are talking about.


If you mean add separate strings then no, I don't see the point.

As for the global variables and those strings, I didn't do that is that because it would be redundant as you wouldn't be using colour codes set as global variables in those strings, and in this case I would have to create separate strings from the current ones like you say as i can't force everything that uses the current strings to use global variables. It may actually have spped benefits though, as well as convience, as generally statusbar, systray and main window title are updated at same time. Of course, it is pretty much neglible as it is only one track. Note I cant do anything about copy string without reimplementing the command since it is implemented in the core (probably).

Not particulary related, but in actual fact, I think I can put my own strings on the main titelformatting page, but I want to maintain my own editor for global help etc. and it will more or less as good in 0.1.1 anyway.


I thought of moving it to a separate component, I just am not sure if it is worth it. In most cases it will only aid convience as you don't have multiple formattings per track like the columns (the only exceptions I can think of right now are albumlist and mass tagger renamer). Having said that, convience is a good enough reason for me, but it also depends on whether stuff in teh string is specific to the ui or even the specific ui component (i.e. foo_ui_columns) and whether anyone will actually implement it into their components to use the global variables. I don't know if it is worth it. And I don't feel like maintaining any more components.


I wrote a long reply about this but I just deleted it all since it was all worthless until i actually look into it. I think it would actually be simpler to implement that I thought anyway, but it would probably involve global variables (like colour scheme) for the global variables since the current global string is track specific.

he meant that the toggle button/bar/area always remains on the very left of the screen, even when the sidebar comes out. The benefit being you don't have to think where to click, it's always in the same place.

Steve

took me a while to figure out what he meant... but what i think he's getting at is being able to double click the far far left of the screen (when foobar is maximised) to show/hide the playlist. It already works at the moment when the playlist is hidden - as you'd expect, but not when it's showing. Strange feature. Maybe a 'double click playlist area to hide/show' would do just as well - conflicts with 'double click playlist to add new playlist'...

Ok thanks.

I don't think I can properly detect a double click on the far left there, I think I would have to to detect double clicks myself...

What about middle clicking on the playlist instead? Middle clicking is not used for anything else there, it might as well be used for something.

I will try to get the former to work anyway.

Or how about in the config screen:

Playlist Area mouse button:
Assign double click to <dropdownlist>
Assign Right click to <dropdownlist>
Assign Middle click to <dropdownlist>

Where dropdownlist is a dropdown (obviously) of things like 'add new playlist', 'hide playlist', 'Nothing', 'add useless feature here'...

Playlist Item mouse button:
Assign Double click to <dropdownlist>
Assign Right click to <dropdownlist>
Assign Middle click to <dropdownlist>

Where dropdownlist = 'rename playlist', 'delete playlist', 'dupliate playlist', 'nothing'

Thanks, Paranoia, you got it.
I didn't really expect my explanation to be good enough, but couldn't figure out how to make it any better.

In Opera, the toggle sidebar in/out is done with a single click, not a double click. The main point of the whole thing is that you can toggle it with your eyes shut. With this solution, you wouldn't have to aim for the border between the sidebar and the playlist. Only an advantage with a maximized window though...

If you can make that work even with e.g. Logitech drivers installed, I guees it's nearly as good as what I suggested above. Anything that makes it easy to toggle it, without aiming the mouse pointer at a hotspot that is 10 pixels wide and changing position depending on toggle state and width of the sidebar, is fine with me.

IMHO ep0ch's idea is quite good too.

edit: grammar

Yes, except I would only want middle click customisable on the playlist view, and Im not sure about making right-click customisable on the playlists.

I would also add drop-downs for double/middle-clicking on empty space in the playlist sidebar/tabs to match. And yandexx requested shift+lmb for remove playlist, so that can be added too..

I will add it to my to-do list anyway..


Does middle clicking work on the tabs/sidebar? I wouldn't have thought there would be a problem, but then I don't have a logitech mouse.

As for your request, I can make it work if you have a border on the sidebar as you will just be clicking on that, but if not the click will select a playlist or something.

So to make it always work I would need a one or two pixel separator on the left of the sidebar.

If that's ok I will add it as an option.

When I middle click inside the sidebar, on the border between sidebar and playlist or on tabs, it looks like this:
While that "mode" is active the playlist will scroll in the direction of mouse movement. I have to middle click once more to return to normal.

This is of course something you choose in the Logitech Mouseware software, and there is alot of middle click actions to choose from. The only reason I mentioned it, is that if you can't override a behavior like this, I assume the new feature won't work for everybody and might cause confusion. I might of course be wrong though...

Yes, that is exactly how it works with Opera. You could say that the sidebar has a border on both sides. Assuming the sidebar is to the left, the left border will be used to toggle and the right border to resize.

Oh noooo, not another tickbox

There is already an option "middle click to delete playlists", if that works then it isnt a problem. Does that autoscroll also happen on the playlist?

More to the point I would rather have autoscroll anyway, i just havent had it since this stupid mouse that wanted intellipoint 5. Mind you I have kind of gotten used to no autoscroll anyway.


I thought about it and basically it would work like this.

First there is a new string which specifies some general variables/settings.

An example:

It would not use tagz or anything and would basically be like settings for the current config.

Then another new string. This would just use tagz, and the variables from above would be passed to this one as extra items. This would set some settings like exposed background, vis foreground etc. The format of this string is more debatable though. I suggest something like this:


Which would just output "variable=value;var2=val2;" etc. It is either that or outputting in some set format like the colour string, or even a separate string for each setting (i.e. background etc.).

Specifying the colours etc. here would be optional (i.e. not replace existing methods), settings would only have to be retrieved from it when it or the first string is modified really. The variables from the first string would also then also be passed on to the current global string as extra items.

What do you think? Or do you have any better ideas, there is an awful lot of strings..

I can't see any workable way to just shove the exposed background etc. colours into the colour string as you say because it is track specific and mixing them up is just going to end up in mess.

I could get away with shoving it all into the current global string though by formatting the string on an empty set of metadata, but that would slow down track stuff as you would unnecessarily be calcuating background colours etc..

None of the middle click features works for me (yes I enabled them before I tested ).
I don't really need the current ones, so that's ok right now. Maybe I don't even need Logitech Mouseware anymore. IIRC I had to intall Mouseware to make everything work as I wanted in Unreal Tournament a while back. As I don't play anymore, I guess I might as well remove it.

Regarding the autoscoll: It also happens on the playlist, but when I activate it inside the playlist itself, the CPU usage goes through the roof (=100%) and scrolling is really slow. If I activate it in the sidebar, or anyware except inside the playlist, the playlist scrolls at a normal speed and the CPU usage is ok.


I got yet another idea (ohh noooo!! ):
I currently use my own modification of picmixers formatting string with this UI. I haven't adopted my "dynamic" formatting to work with this UI because I want something faster this time. The guessing code makes it slow and that seems to be the case even if all tracks are properly tagged. I guess it's the length alone that makes it slow, as it is close to 1300 lines.
Then to my idea:
Would it be possible to add a secondary "globals" section that could be enabled and disabled just like columns can? It could contain guessing code and other touch up features that makes the code slow. This way you would be able to easily remove all this processing intensive code from the processing chain when you don't need it.

An example:

In globals:
my_artist=%artist%

In globals2:
my_artist=alot of guessing code

Artist column:
%_my_artist%

For short the globals2 will be processed after globals, and hence it will update the affected variables. If it is diable all the code in it will be skipped.

Would something like this be possible? Would it, as I hope, make me able to have to versions of the same formatting in one. One really fast requiring proper tags, and one slow but good looking with guessing, without a constant speed penalty like I have in my "dynamic" formatting?

Offtopic posts about foo_osd split to here

Please continue the discussion on foo_osd status bar there.

Doesn't sound good

I hope its not my fault... As long as normal scrolling is ok, I blame the logitech.



If I understood you correctly, Im afraid it wouldn't work in the current form of the global string, because the string has to be executed to determine what variables are in it.

I think it was said already earlier in the thread, you should design your code like

$if2(%artist%,<some guessing code>)

The guessing code is not actually executed if the artist tag is present, well that is what appears to be teh case from using the speed test. Having said that, you probably already do that, your dynamic string is way too long for me to make any sense of.. It doesn't fit into the edit box on the columns ui prefs neither.. whoops.

I think you are right anyway about the length of your string making it slow.

If you meant rather enabling/disabling parts of your code rather than what i first thought (when I didnt realise that you mean disable by "diable"), through a second string that you enable/disable, it is not really worth it, as you could just save to a text file instead, and it would mean I have to format/parse two strings also when it is enabled (depending on what you exactly want/meant). Your example is also kind of redundant as well since you are setting the same variable twice, and would mean I would have to check for that also.

I was considering creating a "sandbox" string/tab just to mess around with though.

You can configure the middle button to produce a middle click by setting the action to AutoScroll.

Hmm, first i'd like to explain the intention behind this idea:
One of the nice things about fb2k is the various amount of plugins which change and add stuff to the display. However, what this also means is that preferences get fragmented all over the place.
Example: lets asume i have made a fb2k-style which covers ui_columns, foo_osd, and has a copy-string and a window-title string.

To give this style to someone he would need to:
1. import the style to ui-columns
2. change various settings in ui-columns, like background-color, vis-color, etc.
3. copy'n paste the osd-string
4. change multiple settings in the osd-preferences
5. copy'n paste the copy-string
6. copy'n paste the window-title string

Thats just not feasible. I have stumbled over this config-fragmentation problem multiple times when i wanted to give a style which i made to someone. Especially if the other person is a non-total-geek, this amount of hassle just to try out this style which i made, is nightmare.

So, my idea basically is an extended version of foo_syfm + ui_columns import/export

In the above quote, you mentioned making the global-string like a separate plugin. Below is an idea on how it could look like, work, and the benefits of it.
Because coming up with good names isn't one of my strengths, i will just call it foo_configurator in this example.

Here's how the config-tree of such a plugin in the fb2k-preferences could look like:






Import/Export:
--------------------------------------
Here the user can import and export all of the settings described below:


Global String:
--------------------------------------
This string could contain any non-track-specific vars. Most importantly color-theme-config, but also other settings.
But there is more to it: there could not just be user-vars but instead other plugins could look for vars which are specific to that plugin.
Example: "ui_columns_color_background=$rgb(0,30,100)" or "osd_color_window_background=$rgb(0,30,100)", or even "osd_font=Arial, MS Sans Serif"

So in other words, color-themes could even include specific fonts and other settings, across different plugins.

For styles with color-themes this should also result in a speedup - example: because the global-string in ui_currently is track-specific color-themes and a possible config-part in the string gets executed multiple times for each track instead of just one time.


Global String (track-specific):
--------------------------------------
This is what the current global-string of ui_columns does. With the difference that other plugins could as well interface with it. This has no speed benefit and is purely because of convenience, since every plugin which supports it would basically just take the string, and execute it for itself, either for the currently playing track, or another track in the playlist - what to do with this string is the choice of the individual plugins.
This string would probably be mostly interesting for tag-guessing and building track-dependend vars.



Plugin-specific configpages:
--------------------------------------
This is were the real fun begins. I am not sure if this is technically possible, so it may very well be that this is an utopian idea - however, i hope its not.
Other installed plugins could check if foo_configurator is installed, and if yes, create their own config-page in ui_configurator - and mirror some of their settings there.
So, for example the foo_osd plugin could have its config-page at two places - its native one, and a sub-page in ui_configurator. Both pages would be synchronized against each other - so they're basically just a mirror.
Okay, now this would all be total nonsense without a benefit: when importing/exporting configurations, then those sub-pages in ui_configurator would be taken into account as well.
Maybe it could also work the other way around sometimes: not another plugin supporting foo_configurator, but instead foo_configurator i.e. creating a mirror page of the copy-string.


The result of the above - if technically possible - could be that a user just has to download a single config-file containing a foobar-style, import it, and then automatically has all the affected plugins configured to match that style.
Not just colors, but also strings, font-settings, etc.

- Lyx

P.S.: You mentioned that the copy-string may be built into the core. Am i right to guess that since its configured under the standard-gui, that the standard_gui someway interfaces with it? If yes, couldn't any other plugin do this as well then? (i.e. foo_configurator)

First off, I would like to say I love the colums_ui, but have a question about a specific preset (plisk_0.1.5), How do I sort by the artists name instead of the ablum's name?

@musicmusic:
It seems I have a major problem explaining my ideas. Sorry about that. I still believe the idea is good though.

Just to confirm, I really ment to really disable parts of the global code, not just skip a part of an $if() statement. I don't really know all the technical terms, and that makes it even more difficult, but if I'm not mistaken, the word "parse" means interpreting the code on runtime. If so, then disabling code by using an $if() statement (with alot of contents) still means it has to be parsed. Right? TAGZ isn't really suited for constructing guessing code, and if you still want to do it, and catch alot of exceptions, then it turns out pretty long. Not much to do about that.

Anyway, I kind of got a better idea last night, "Global extensions". Although my plan was to make a long explanation later with pictures and all, I'll try to give it here instead with some ASCII art.

Description of the idea:
You keep the global section as is, but makes it possible to extended it with these "extensions". An extension is a separate part of code located in it's own input box/formatting window, that can be inserted into the global section. All of these extension are localized under a new tab called "extentions" following the already present "Global" and "Colours (Global)" tabs. In this new tab, extentions can be enabled/disabled, created and deleted, alot like how columns work now. The enable/disable checkbox would make it easy for users (as in not only the creator) of a formatting to turn features on and off, something that IMHO is currently not that easy to communicate to everyone. A checkbox is alot more intuitive than starting a code with a config section using e.g. $puts(Caps_first_letter,1) where 1=yes and 0=no. Below in an example of how I imagine it implemented in this tab:
Extension 3 shows an example.

The Edit button opens a pop up window containing three input boxes. One with the code, one with the "description" input and one with the contents of "More Info".

The "More Info" button opens a popup with additional info about this setting/extension. Just in case the user would like more info than the "description" gives.

The first checkbox is associated with a new variable available in the global section, called e.g. %__ext_1% (true/false depending on the state of the checkbox). It could be used like this in the global section:
$if(%__ext_1%, $execute_extension(1))


When this line is reached in the global section, the code associated with that extension is parsed/prosessed/executed (whatever the right word is...) if the checkbox is checked, before it continues to the next line in the global string.

As I see it, you still have only one globals section, but the contents of it would be more dynamic. The benefits are (I hope) that you don't need to parse alot of code that won't be used (e.g. guessing, touch up like $chaps2(), remove underscore...) and it would be alot easier for users without formatting/coding knowledge to utilize the options the creator of the formatting has made available to them. To make this work for chooseing color themes too I guess you might need radio buttons

So, did I manage to explain my idea this time? If so, does it sound like a good idea, or is it way "over the top"?
And, am I by any chance your worst nightmare?


Oh, by the way, could you make the current time and date available as metadata? I thought I could use it in combination with foo_playcount to highlight tracks in the playlist that has been played today. I have foo_history already, but I would like to see this in my playlist too.

Edit: Added two more buttons to the ascii art
Edit2: spelling
Edit3: Turned the last extension in the ascii art into an example

I had this idea too.. tried to code it into my columns, and realised there was no way of calling up the system date. I had it theoretically working - I just had to put the date in the code myself... kinda sucked

It would be a nice addition, but I don't know whether musicmusic could this, or whether it would be down to the fb2k developers.

Steve

My guess is that he can do it, as both foo_history and foo_playcount has access to the system date. Besides, he has shown already that he can create variables. So. my hopes are high
Not that this is the killer feature...

is there any advantage in having a seperate global-colorstring page?

I mean, couldn't ui_columns instead just look for certain vars in the global-string?
example:

ui_columns_global_track_column_foreground=CCCCCC
ui_columns_global_track_column_foreground_selected=FFFFFF
ui_columns_global_track_column_background=000000
ui_columns_global_track_column_background_selected=555555

If technically feasible, we could then just drop one page of the ui_columns prefs. And instead rename the current global-string to "global (track specific)".

And then add a new 2nd global string containing vars which are not track-specific(only get executed one time).

In such a case the new "globals" page of ui_columns would contain two tabs:
"Global" and "Global (track-specific)


disadvantage: breaks backwards-compatibility (because of the removed global colorstring).

- Lyx

possible bug:

just paste the following color-string either in the global-colorstring or a column-colorstring:

00FF00|00FF00|000000|000000

the selected text will appear pink instead of green.

this seems to only affect the 2nd color in a colorstring(foreground, selected).

- Lyx

Appears green for me.

Steve

Tried in both global and columns, and both normal and selected text appeared green as they should...