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: question about ui_extension API (Read 16584 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

question about ui_extension API

It's me again complaining about some errors/bugs (I'm not really shure if these things are errors, it could also be me and my stupidity    )

-I tried to compile foo_static_panel, it complains about
Code: [Select]
foo_static_panel\static_window.cpp(146) : error C2065: 'WC_STATIC' : undeclared identifier


edit: Replaced WC_STATIC with "STATIC" and now it seems to work

- foo_search_ex compiles, but the undock command doesn't work correctly. If you press 'undock', the panel undocks but it is still a panel window with no titlebar and stuff.

- foo_uie_albumlist gives this:
Code: [Select]
--------------------Configuration: foo_uie_albumlist - Win32 Debug--------------------
Compiling resources...
Compiling...
main.cpp
...foo_uie_albumlist\main.cpp(712) : warning C4355: 'this' : used in base member initializer list
...foo_uie_albumlist\main.cpp(780) : error C2065: 'TreeView_SetLineColor' : undeclared identifier
...foo_uie_albumlist\main.cpp(903) : error C2065: 'TVS_NOHSCROLL' : undeclared identifier
Error executing cl.exe.

foo_uie_albumlist.dll - 2 error(s), 1 warning(s)


- and last but not least: foo_uie_dbexplorer also complains about an undeclared  'TreeView_SetLineColor'





And now to something complete different:
I looked at the source for the first time and i didn't quite understand the concept. ( Yes, I looked through the example extensions but most of the time it was like  or  )

My understanding is as follows: Every single extension is a ui_extension from which multiples can be grouped with the help of a ui_extension_host. Am I right that there are three different host in foo_ui_columns? One for the sidebar, one for the toolbar and one for the playlist?

Another thing is the case 0 and case 1 stuff mentioned in the comments. Am I right that case 0 functions are called only when for example foo_ui_columns is loaded and that case 1 functions are responsible for the 'true' work of the extension?

The function is_available() is called from the host if for example the user has chosen to add an extension to a panel. So if I want my extension to have only one instance I have to return false after the first 'window' is created? Speaking of single instance, what's the difference between ui_extension_factory and ui_extension_single_factory?

edit:
After getting foo_static_panel to compile there is one thing i do not understand: You can have a static panel open in both the sidebar and the toolbar. In static_window i can only find a single 'HWND wnd_host', so how does this work? I think it has something to do that it is ui_extension_factory and not ui_extension_single_factory but for now I'm quite confused



Sorry if the above are stupid questions but as soon as some fancy OO design template things and stuff appears in source code my understanding becomes nearly zero. I learned much from the foobar SDK but sadly it is yet not enough to understand all the things which are done in there 

question about ui_extension API

Reply #1
WC_STATIC, TreeView_SetLineColor: Seems like you need a newer version of the Platform SDK.

Quote
My understanding is as follows: Every single extension is a ui_extension from which multiples can be grouped with the help of a ui_extension_host. Am I right that there are three different host in foo_ui_columns? One for the sidebar, one for the toolbar and one for the playlist?

That's about right. I'm not sure about the actual number of host implementations in foo_ui_columns right now; I think I only detected two, when I tried enumerating ui_extension_hosts.

Quote
Another thing is the case 0 and case 1 stuff mentioned in the comments. Am I right that case 0 functions are called only when for example foo_ui_columns is loaded and that case 1 functions are responsible for the 'true' work of the extension?

'Case 0' is for querying information about an extension without creating a window. 'Case 1' is for managing an 'active' extension, i.e. window creation, destruction and transfer to a new host.

Quote
The function is_available() is called from the host if for example the user has chosen to add an extension to a panel. So if I want my extension to have only one instance I have to return false after the first 'window' is created? Speaking of single instance, what's the difference between ui_extension_factory and ui_extension_single_factory?

The 'single' version of the ui_extension factory returns the same object everytime, while the normal version creates new a object when it is called. Use the 'single' version for a singleton extension.

Quote
Sorry if the above are stupid questions but as soon as some fancy OO design template things and stuff appears in source code my understanding becomes nearly zero. I learned much from the foobar SDK but sadly it is yet not enough to understand all the things which are done in there 

I'd like to add a part about implementing a ui_extension to my tutorial - or create a new tutorial for that - but I currently don't have time for that. In the meantime, you might fing this useful. Some time ago, I started rewriting the documentation in the ui_extension include files as doxygen comment. This work is not completely finished though.

You might also be interested in ui_extension_helper.h from my foosion_helpers library. It implements a template class (don't worry, it's simple to use) that takes care of most of the basic tasks involved in implementing a ui_extension. Example:
Code: [Select]
#include "../SDK/foobar2000.h"
#include "../ui_extension/ui_extension.h"
#include "../foosion_helpers/ui_extension_helper.h"

// add other includes you might need

// for this example, we create a sidebar extension that supports multiple instances
class my_extension : public ui_extension_base_t< UET_PANEL, UEM_MULTIPLE >
{
   virtual const GUID & get_extension_guid() {
       // replace this with your own GUID to avoid clashes with the history toolbar :)
       // {FCA54897-6BD0-438c-B63E-91E987AEDB51}
       static const GUID guid =
       { 0xfca54897, 0x6bd0, 0x438c, { 0xb6, 0x3e, 0x91, 0xe9, 0x87, 0xae, 0xdb, 0x51 } };
       return guid;
   }

   virtual void get_name(string_base & out) {
       out = "My panel";
    }

   virtual void get_category(string_base & out) {
       out = "General";
    }

   virtual HWND create_window(HWND wnd_parent) {
       // TODO: create your window here
       return NULL;
   }

   // add any needed fields and methods
}

The ui_extension_base_t class takes care of transfering your extension to a new host, so unless you need to do something in that event, you shouldn't have to worry about that. The code currently does not handle docking and undocking, only host-to-host transfers. The first template parameter determines the type of your extension (a combination of UET_* flags), the second parameter determines the multiplicity (UEM_MULTIPLE or UEM_SINGLE for a multiple resp. single instance extension). I admit I haven't really tested the single instance case, so better be careful.

Edit: A sidebar panel called "My toolbar" in the "Toolbars" category?

question about ui_extension API

Reply #2
Quote
It's me again complaining about some errors/bugs (I'm not really shure if these things are errors, it could also be me and my stupidity    )

-I tried to compile foo_static_panel, it complains about
Code: [Select]
foo_static_panel\static_window.cpp(146) : error C2065: 'WC_STATIC' : undeclared identifier


edit: Replaced WC_STATIC with "STATIC" and now it seems to work
I think you need to update your platform sdk, but yeah it should be defined to "Static".

Quote
- foo_search_ex compiles, but the undock command doesn't work correctly. If you press 'undock', the panel undocks but it is still a panel window with no titlebar and stuff.
It works here, what OS are you on? It was a bit dodgy though.

Quote
- foo_uie_albumlist gives this:
Code: [Select]
--------------------Configuration: foo_uie_albumlist - Win32 Debug--------------------
Compiling resources...
Compiling...
main.cpp
...foo_uie_albumlist\main.cpp(712) : warning C4355: 'this' : used in base member initializer list
...foo_uie_albumlist\main.cpp(780) : error C2065: 'TreeView_SetLineColor' : undeclared identifier
...foo_uie_albumlist\main.cpp(903) : error C2065: 'TVS_NOHSCROLL' : undeclared identifier
Error executing cl.exe.

1. Don't matter
2. & 3. I define _WIN32_IE_ as 0x501, which means I require IE 5.5, Windows 2000 or Me or newer OSs. TreeView_SetLine and TVS_NOHSCROLL colour requires _WIN32_IE_ defined as >= 0x500. Update your platform SDK if neccessary. If you want to support older OSs, you need to check the version of comctl32.dll at runtime. (See here)

Quote
- and last but not least: foo_uie_dbexplorer also complains about an undeclared  'TreeView_SetLineColor'
As above.

Quote
And now to something complete different:
I looked at the source for the first time and i didn't quite understand the concept. ( Yes, I looked through the example extensions but most of the time it was like   or  )

My understanding is as follows: Every single extension is a ui_extension from which multiples can be grouped with the help of a ui_extension_host. Am I right that there are three different host in foo_ui_columns? One for the sidebar, one for the toolbar and one for the playlist?

Currently, the playlist is not a ui_extension, and so there are two hosts (toolbars, sidebar).

For each ui_extension instance, there is an instance of the ui_extension class.
Quote
Another thing is the case 0 and case 1 stuff mentioned in the comments. Am I right that case 0 functions are called only when for example foo_ui_columns is loaded and that case 1 functions are responsible for the 'true' work of the extension?
Case 0 are called anytime. The point is that get_name() etc. may be called before init_or..(), which may not even be called, in the case the host is just pulling info it will destroy you (multiple instance extensions only). There was a pretty diagram that I copied from elsewhere that reid to explain it, its not particulary important unless you do dodgy things..

Quote
The function is_available() is called from the host if for example the user has chosen to add an extension to a panel.
Yes, it is called at other times too (e.g. when showing context menu).

Quote
So if I want my extension to have only one instance I have to return false after the first 'window' is created?
No. You must return false if you are a single instance extension and if the host pointer equals your current host (or compare the guids, same thing). If you are already created, you are returning whether you are available for another host to take control of you. Like moving the extended search from the sidebar to the toolbar/somewhere else, with it being automatically removed from the sidebar, so the user doesn't face annoying errors or unexpected behaviour. If you don't want to allow for that to happen, you can return false if you want.

Quote
Speaking of single instance, what's the difference between ui_extension_factory and ui_extension_single_factory?
the latter uses a single static instance of your class, with its reference count fixed at 1, whilst the former uses many.

Quote
Sorry if the above are stupid questions but as soon as some fancy OO design template things and stuff appears in source code my understanding becomes nearly zero. I learned much from the foobar SDK but sadly it is yet not enough to understand all the things which are done in there 
[a href="index.php?act=findpost&pid=248448"][{POST_SNAPBACK}][/a]

I don't know if you would find themn useful, but foosion has made some kind of helpers in his foosion_helpers library.
.

question about ui_extension API

Reply #3
Thanks a lot for your answers, most of the things are a lot clearer now


After starring at the SDK for 2 days I think most of my problems comes from the fact that I do not fully understand the concept of services. I think I basically understand for what services can be used for but what I don't get is the mechanism behind the different service_factory_* things. I know that they are used to 'initialize' the services but I don't get what the differences between them are.

Quote
the latter uses a single static instance of your class, with its reference count fixed at 1, whilst the former uses many.


I don't get why more than one instance of the class could be created and 'who' is responsible for this. It make sense that e.g. there is only one instance of a playback_flow_control and it makes also sense tha there could be more than one instances of ui_extension but as said above I don't understand where these multiple instances are created.

It would be very helpfull if someone could give me a hint for this.





@musicmusic
The problem with the undocking of foo_ex_search occurs on Win XP Prof SP1

question about ui_extension API

Reply #4
A service factory is responsible for creating service instances. A service factory will normally create a new service instance, when its instance_create() method is called. This is necessary if you want to use a specific service implementation which has a state (example: a Musepack decoder) for different tasks simultanously (example: decoding multiple Musepack files at the same time (playback and replaygain scanning)). On the other hand, there are service implementations without a state (example: initquit) or services with only a single, static implementation (example: console, playlist_oper). The latter would use a service_factory_single_t which manages exactly one service instance and merely returns a pointer to it, when its instance_create() method is called.

question about ui_extension API

Reply #5
Quote
Quote
- foo_search_ex compiles, but the undock command doesn't work correctly. If you press 'undock', the panel undocks but it is still a panel window with no titlebar and stuff.
It works here, what OS are you on? It was a bit dodgy though.[a href="index.php?act=findpost&pid=248488"][{POST_SNAPBACK}][/a]

I'm seeing the same thing. Replacing:

Code: [Select]
UpdateWindow(g_wnd);

in the menu handler with:

Code: [Select]
SetWindowPos(g_wnd,0,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE|SWP_NOZORDER|SWP_FRAMECHANGED);

fixed it (on XP-SP1, at least).

question about ui_extension API

Reply #6
Quote
Quote
Quote
- foo_search_ex compiles, but the undock command doesn't work correctly. If you press 'undock', the panel undocks but it is still a panel window with no titlebar and stuff.
It works here, what OS are you on? It was a bit dodgy though.[a href="index.php?act=findpost&pid=248488"][{POST_SNAPBACK}][/a]

I'm seeing the same thing. Replacing:

Code: [Select]
UpdateWindow(g_wnd);

in the menu handler with:

Code: [Select]
SetWindowPos(g_wnd,0,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE|SWP_NOZORDER|SWP_FRAMECHANGED);

fixed it (on XP-SP1, at least).
[a href="index.php?act=findpost&pid=248910"][{POST_SNAPBACK}][/a]

I reproduced it by disabling visual themes. Thanks, I'll add your fix at some point. Maybe I should fix up foo_history_panel as well, in case anyone uses it as a reference..
.

question about ui_extension API

Reply #7
I've been thinking about how to correctly navigate around the tabbed panel ui extension host I just posted. Doesn't it make sense for the owner of an extension (i.e., the extension host instance) to control which window gets the keyboard focus next, rather than relying on ui_extension::g_on_tab()? I'm thinking of a function like:

Code: [Select]
void ui_extension_host::pwn_my_focus(HWND)

I'm still fumbling my way around the windows sdk, so I may be totally wrong, but this seems logical to me.


edit: relinquish_focus makes no sense as a method name in ui_extension_host

question about ui_extension API

Reply #8
Quote
I've been thinking about how to correctly navigate around the tabbed panel ui extension host I just posted. Doesn't it make sense for the owner of an extension (i.e., the extension host instance) to control which window gets the keyboard focus next, rather than relying on ui_extension::g_on_tab()? I'm thinking of a function like:

Code: [Select]
void ui_extension_host::pwn_my_focus(HWND)

I'm still fumbling my way around the windows sdk, so I may be totally wrong, but this seems logical to me.
[a href="index.php?act=findpost&pid=249484"][{POST_SNAPBACK}][/a]

Maybe, you would definitely need a specific handler for when the tab key is pressed because it reverses order when the shift key is held down.

But all I would do in such a handler is call ui_extension::g_on_tab anyway. In fact, I am already intercepting all TAB key presses for windows that do not return DLGC_WANTALLKEYS, DLGC_WANTMESSAGE or DLGC_WANTTAB in their WM_GETDLGCODE handler to fix tabbing in dialog panels, which would usually tab to the next control in the dialog instead of the main window.

ui_extension::g_on_tab() is meant for windows that do not use dialog manager, or return one of the above flags in WM_GETDLGCODE.

I think your problems stem from the fact that you are creating the panel windows as a child window of the tab control instead of the dialog. The tab control automatically dumps itself at the bottom of the z-order anyway.

I can't really see what tabbing/navigation problems you would have then, TAB would stop at both the tab control and the panel, and whilst the tab control has the focus, the left and right keys can be used to switch tab.
.

question about ui_extension API

Reply #9
Quote
Quote
I've been thinking about how to correctly navigate around the tabbed panel ui extension host I just posted. Doesn't it make sense for the owner of an extension (i.e., the extension host instance) to control which window gets the keyboard focus next, rather than relying on ui_extension::g_on_tab()? I'm thinking of a function like:

Code: [Select]
void ui_extension_host::pwn_my_focus(HWND)

I'm still fumbling my way around the windows sdk, so I may be totally wrong, but this seems logical to me.
[a href="index.php?act=findpost&pid=249484"][{POST_SNAPBACK}][/a]


I think your problems stem from the fact that you are creating the panel windows as a child window of the tab control instead of the dialog. The tab control automatically dumps itself at the bottom of the z-order anyway.

I can't really see what tabbing/navigation problems you would have then, TAB would stop at both the tab control and the panel, and whilst the tab control has the focus, the left and right keys can be used to switch tab.
[a href="index.php?act=findpost&pid=249503"][{POST_SNAPBACK}][/a]


Ah right, thanks for the tip. I guess I should work on my own problems before suggesting api changes in the future. 

question about ui_extension API

Reply #10
Quote
@musicmusic and Phi

I don't know where to put this, therefore I'll try it here:

In the foo_temple thread upNorth suggested the following

Quote
Suggestion:
Maybe you need to talk to Phi, but it would be nice if "show list when enqueuing files" also worked with foo_uie_tabs (focus the foo_temple tab when a track is enqueued). It would be even better if it remembered the tab it stole focus from, and gave focus back after last song, but only if "after last song|hide list" is checked and if foo_temple tab is focused at that time.


I think of a way where an extension could post a  "make me visible" request to its host. The columns ui host would do nothing but foo_uie_tabs could make the tab with the extension visible.

Do you think adding such a feature to the extension API would make sense?

edit: typos
edit2: typos... 
[a href="index.php?act=findpost&pid=251783"][{POST_SNAPBACK}][/a]

Yes, I thought the same when I saw foo_uie_tabs..

Something like bool ui_extension_host::show_window(HWND wnd), and maybe also bool ui_extension_host::is_visible(HWND wnd).

Its not really "my" api anymore, I mean there are third-party hosts and extensions, so if you think its important it would be worthwhile sorting it out now, as opposed to later.

You guys are developing panels, so my questions are:
1) Should we keep compatibility? I don't know to what extent this would be possible, or worthwhile, I mean extensions would have to deal with different host versions as well as vice-versa. Its not like the authors of the current extensions aren't around to recompile, and there aren't that many, so my opinion is no.
2) What other changes should be made? E.g. are you happy with the way adding items to the host context menu is handled? Its worthwhile esablishing everything/as many things as possible that should be changed so it can be done in one go.
.

question about ui_extension API

Reply #11
Quote
Its not really "my" api anymore,...

Of course it's yours, who else can we blame if something goes wrong? Ehm, just kidding

Quote
1) Should we keep compatibility? I don't know to what extent this would be possible, or worthwhile, I mean extensions would have to deal with different host versions as well as vice-versa. Its not like the authors of the current extensions aren't around to recompile, and there aren't that many, so my opinion is no.


I think it's very important to keep compatibility, because i don't feel like implementing 3 different versions of ui_extension in my plugin to satisfy everyones needs. Of course there are only 2 different hosts available but who knows what will happen in the future.
Also I think that the current API is near a final state, I thought a long time about alternative hosts and their functionality and I don't really see that much additions which should be made to the API. Read down below for more.

Quote
2) What other changes should be made? E.g. are you happy with the way adding items to the host context menu is handled? Its worthwhile esablishing everything/as many things as possible that should be changed so it can be done in one go.


I can't say anything about the menu handly stuff because my coding knowledge isn't that good to think of a better way. You better ask Phi and foosion for this.

I think at least the "Show me/Hide me" stuff should be added to the 'official' API. For the columns ui host this doesn't make any sense but in uie tabs this would be very usefull. A "Show me" in uie tabs would switch to the tab containing the extension and "Hide me" would switch to the previous selected tab.

One thing where these commands could be usefull in the columns ui host is if you implement some rollup/rolldown functionality to your host. Look at http://www.codeproject.com/miscctrl/rollupctrl.asp for such a control. At the company I work we use these kind of controls to handle a huge amount of sidebar plugins and I really love this feature. If you don't really need a plugin you can easily roll it up and then make it usable again with just one click. With implemented "Show me/Hide me" functions a plugin then could rollup/rolldown itself.


Besides the show/hide commands I can't think of any additions which would be usefull.

But perhaps there could be some general kind of 'command'-function, like host->do_command(HC_DOSOMESTUFF) with which a plugin could make use of non standard host functions. Also perhaps there should be some kind of 'get_host_type' or 'get_api_version' or something similar.
I don't know if this things are usefull in the current state, I just want to throw these things into this discussion.

question about ui_extension API

Reply #12
Quote
You guys are developing panels, so my questions are:
1) Should we keep compatibility? I don't know to what extent this would be possible, or worthwhile, I mean extensions would have to deal with different host versions as well as vice-versa. Its not like the authors of the current extensions aren't around to recompile, and there aren't that many, so my opinion is no.

No, I don't see a need to. These changes will be minor, and yeah all of the useful extensions are still being actively developed.

Quote
2) What other changes should be made? E.g. are you happy with the way adding items to the host context menu is handled? Its worthwhile esablishing everything/as many things as possible that should be changed so it can be done in one go.
[a href="index.php?act=findpost&pid=252084"][{POST_SNAPBACK}][/a]

I really can't think of anything else that I would change. Except for this minor detail:
Code: [Select]
virtual unsigned get_supportted_types()=0;

Its supported.

Quote
I think it's very important to keep compatibility, because i don't feel like implementing 3 different versions of ui_extension in my plugin to satisfy everyones needs. Of course there are only 2 different hosts available but who knows what will happen in the future.

I think by "compatibility" musicmusic means will extensions compiled for the old api still work with the new one, which you won't need to worry about if we intend to update our extensions after the new api is finalised.

question about ui_extension API

Reply #13
Yeah, I think I understood the compatibility thing wrong, stupid me 

So i vote also for 'No' concerning the compatibility.

question about ui_extension API

Reply #14
As far as naming is concerned, see the Changes paragraph in here for my propositions.

I agree that a way to control the visibility of extensions would be useful. I'd call the methods is_visible() and ensure_visible(). I'm not convinced that a way to hide an extension is really that useful, and hiding will likely not be supported by every host or in every situation. At least the name of the method should indicate that it may fail.

Quote
But perhaps there could be some general kind of 'command'-function, like host->do_command(HC_DOSOMESTUFF) with which a plugin could make use of non standard host functions.
Special functions can easily be dealt with by using a ui_extension_host subclass and the service_query() method.

Quote
Also perhaps there should be some kind of 'get_host_type' or 'get_api_version' or something similar.
Do you mean something beyond the current get_supported_types() method? Also different API versions imply different GUIDs for the ui_extension_host service.

question about ui_extension API

Reply #15
Quote
Quote
But perhaps there could be some general kind of 'command'-function, like host->do_command(HC_DOSOMESTUFF) with which a plugin could make use of non standard host functions.
Special functions can easily be dealt with by using a ui_extension_host subclass and the service_query() method.

I knew there was a better way...

Quote
Quote
Also perhaps there should be some kind of 'get_host_type' or 'get_api_version' or something similar.
Do you mean something beyond the current get_supported_types() method? Also different API versions imply different GUIDs for the ui_extension_host service.

I was misleaded at first by the compatibility stuff so this doesn't make any sense 

question about ui_extension API

Reply #16
Quote
I can't say anything about the menu handly stuff because my coding knowledge isn't that good to think of a better way. You better ask Phi and foosion for this.
It doesn't really both me anyway.

Quote
I think at least the "Show me/Hide me" stuff should be added to the 'official' API. For the columns ui host this doesn't make any sense but in uie tabs this would be very usefull. A "Show me" in uie tabs would switch to the tab containing the extension and "Hide me" would switch to the previous selected tab.
I agree about the showing stuff, but in what situation would "Hide me" be useful?

Quote
One thing where these commands could be usefull in the columns ui host is if you implement some rollup/rolldown functionality to your host. Look at http://www.codeproject.com/miscctrl/rollupctrl.asp for such a control. At the company I work we use these kind of controls to handle a huge amount of sidebar plugins and I really love this feature. If you don't really need a plugin you can easily roll it up and then make it usable again with just one click. With implemented "Show me/Hide me" functions a plugin then could rollup/rolldown itself.[a href="index.php?act=findpost&pid=252156"][{POST_SNAPBACK}][/a]
Im not sure exactly what your roll-up does, but if you mean something like double clicking on the panel caption in the sidebar would hide or show the panel, that would be handled by the host anyway, so "Hide me" isnt necessary for that.

Quote
No, I don't see a need to. These changes will be minor, and yeah all of the useful extensions are still being actively developed.
Ok.

Quote
I really can't think of anything else that I would change. Except for this minor detail:
Code: [Select]
virtual unsigned get_supportted_types()=0;

Its supported. [a href="index.php?act=findpost&pid=252161"][{POST_SNAPBACK}][/a]
Whoops

Quote
        * renamed ui_extension_single_factory to ui_extension_factory_single to comply with foobar2000 naming scheme
        * added ui_extension_factory_single_transparent
        * corrected typo in ui_extension_host::get_supported_types
        * renamed ui_extension::find_by_guid to create_by_guid since that name provides a better indication that you have to service_release() the returned value (if non-null)[a href="index.php?act=findpost&pid=252204"][{POST_SNAPBACK}][/a]
Ok thats all cool.

The other things I was thinking was a bool ui_extension_host::request_resize(unsigned flags, unsigned width, unsigned height) method, and maybe something to default to inserting new instances for an extension like Phi's spacer toolbar like mentioned in the columns ui thread.
.

question about ui_extension API

Reply #17
Quote
Quote
I think at least the "Show me/Hide me" stuff should be added to the 'official' API. For the columns ui host this doesn't make any sense but in uie tabs this would be very usefull. A "Show me" in uie tabs would switch to the tab containing the extension and "Hide me" would switch to the previous selected tab.
I agree about the showing stuff, but in what situation would "Hide me" be useful?


see below

Quote
Quote
One thing where these commands could be usefull in the columns ui host is if you implement some rollup/rolldown functionality to your host. Look at http://www.codeproject.com/miscctrl/rollupctrl.asp for such a control. At the company I work we use these kind of controls to handle a huge amount of sidebar plugins and I really love this feature. If you don't really need a plugin you can easily roll it up and then make it usable again with just one click. With implemented "Show me/Hide me" functions a plugin then could rollup/rolldown itself.[a href="index.php?act=findpost&pid=252156"][{POST_SNAPBACK}][/a]
Im not sure exactly what your roll-up does, but if you mean something like double clicking on the panel caption in the sidebar would hide or show the panel, that would be handled by the host anyway, so "Hide me" isnt necessary for that.


Each RollUp panel has a button on top which toggles the visibility of the panel. If the panel is visible and the button is pressed the height of the panel is minimized and you can only see the button left. Another press reshows the panel. I agree with you that a "Hide me" is not needed for this

But for at least one situation a "Hide me" function would be usefull anyway. If in foo_temple the enqueue list is empty the plugin could send a "Hide me" to the host to hide itself. For the RollUp/RollDown panel it would be a RollUp and in uie tabs it could switch back to the previous tab.

Altough a "Hide me" is pretty useless for now except from the situation with foo_temple I think it is kind of consequent that if we add a "Show me" we should also add a "hide me".

question about ui_extension API

Reply #18
Quote
Each RollUp panel has a button on top which toggles the visibility of the panel. If the panel is visible and the button is pressed the height of the panel is minimized and you can only see the button left. Another press reshows the panel. I agree with you that a "Hide me" is not needed for this

But for at least one situation a "Hide me" function would be usefull anyway. If in foo_temple the enqueue list is empty the plugin could send a "Hide me" to the host to hide itself. For the RollUp/RollDown panel it would be a RollUp and in uie tabs it could switch back to the previous tab.

Altough a "Hide me" is pretty useless for now except from the situation with foo_temple I think it is kind of consequent that if we add a "Show me" we should also add a "hide me".
[a href="index.php?act=findpost&pid=252451"][{POST_SNAPBACK}][/a]

Maybe. I don't agree with the example of foo_uie_tabs though, I mean if a user selected that tab they probably wouldn't really want it to be switch back later, and it wouldn't be particularly intiuative as it would switch to a tab that the user may not want to see. That's not to say it may not have a usee in other situations, maybe a vis panel in foo_floater or something.

It would be ideal if this was sorted out before columns ui 0.1.2 so ill try and revise the api soon, unless anyone else feels making the changes listed in this thread. And then probably another beta of columns ui to test things.
.

question about ui_extension API

Reply #19
@musicmusic: Here is my original request to janjan about the show/hide feature.
Quote
Suggestion:
Maybe you need to talk to Phi, but it would be nice if "show list when enqueuing files" also worked with foo_uie_tabs (focus the foo_temple tab when a track is enqueued). It would be even better if it remembered the tab it stole focus from, and gave focus back after last song, but only if "after last song|hide list" is checked and if foo_temple tab is focused at that time.[a href="index.php?act=findpost&pid=249756"][{POST_SNAPBACK}][/a]

I don't know if you use foo_temple yourself, but the window version can pop up when you enqueue a file, and then hide again when the file has been played. My thought was to transfer this behavior to foo_uie_tabs, or a roll up panel if that's the next big thing.

At the moment you enqueue files, manually switch to it's tab to see the files, and when it's finished you're left with an empty tab. Of course this isn't a major problem, far from it, but if possible, I would prefere to look at any other tab than this empty one. See the quote above for a possible solution. This means that
Quote
if a user selected that tab they probably wouldn't really want it to be switch back later
doesn't really fit as a description of the scenario I'm trying to describe.

Edit: spelling

question about ui_extension API

Reply #20
Quote
@musicmusic: Here is my original request to janjan about the show/hide feature.
Quote
Suggestion:
Maybe you need to talk to Phi, but it would be nice if "show list when enqueuing files" also worked with foo_uie_tabs (focus the foo_temple tab when a track is enqueued). It would be even better if it remembered the tab it stole focus from, and gave focus back after last song, but only if "after last song|hide list" is checked and if foo_temple tab is focused at that time.[{POST_SNAPBACK}][/a]

I don't know if you use foo_temple yourself, but the window version can pop up when you enqueue a file, and then hide again when the file has been played. My thought was to transfer this behavior to foo_uie_tabs, or a roll up panel if that's the next big thing.

At the moment you enqueue files, manually switch to it's tab to see the files, and when it's finished you're left with an empty tab. Of course this isn't a major problem, far from it, but if possible, I would prefere to look at any other tab than this empty one. See the quote above for a possible solution. This means that
Quote
if a user selected that tab they probably wouldn't really want it to be switch back later
doesn't really fit as a description of the scenario I'm trying to describe.

Edit: spelling

[a href="index.php?act=findpost&pid=252693"][{POST_SNAPBACK}][/a]

No I don't use the plugin, so it doesn't matter really

So the revised api is looking like [a href="http://members.lycos.co.uk/musicf/ui_extension_rerevised.txt]this[/url]. I think I covered everything, if not or you have any other suggestion, please post back.
.

question about ui_extension API

Reply #21
Not directly an api issue, but I was thinking it would make more sense to use the "Panels" category for panels instead of "General", which is just confusing. (And since the compatibility with the current api will be broken with the new one, it would be the perfect time to do this)

Visualisations could go under the "Visualization" category then. What do you guys think?
.

question about ui_extension API

Reply #22
Quote
Not directly an api issue, but I was thinking it would make more sense to use the "Panels" category for panels instead of "General", which is just confusing.
"Sidebar" would be ok as well, though maybe not as good as "Panels".

Quote
Visualisations could go under the "Visualization" category then.
Simple spectrum already is in that category; I'm all for this change.

I hope to find some time this weekend to update my doxygen version of the ui_extension API to the latest version. I could include same categorizing guidelines as well, if you think that we need more than "Toolbars", "Panels" and "visualization".

question about ui_extension API

Reply #23
Quote
Quote
Not directly an api issue, but I was thinking it would make more sense to use the "Panels" category for panels instead of "General", which is just confusing.
"Sidebar" would be ok as well, though maybe not as good as "Panels".[a href="index.php?act=findpost&pid=254852"][{POST_SNAPBACK}][/a]
Ok cool, I was thinking about coherence with "Toolbars" when choosing "Panels" really.

Quote
Quote
Visualisations could go under the "Visualization" category then.
Simple spectrum already is in that category; I'm all for this change.[a href="index.php?act=findpost&pid=254852"][{POST_SNAPBACK}][/a]
Where do you think I got it from  Of course, I missed an 's' and the end though.

Quote
I hope to find some time this weekend to update my doxygen version of the ui_extension API to the latest version. I could include same categorizing guidelines as well, if you think that we need more than "Toolbars", "Panels" and "visualization".
[a href="index.php?act=findpost&pid=254852"][{POST_SNAPBACK}][/a]
I made a couple other minor changes since the above version of the api, I may make a couple more whilst I implement it. I will hopefully be done by the weekend, I guess I will upload the new sdk so you can review it. So start commentting now if you want, or wait until later. Either way, it would be useful to merge your doxygen comments into my distribution. Do you want your helpers in there as well?

As for other categories, I was thinking that Phi's idea for separator panels (vertical/horizontal) splitters would be the best idea for customising the columns ui display. I.e. make the area currently covering the sidebar/playlist a host which you can split up using these host-panel things. I haven't thought about it much, but it seemed the sanest idea to me.

Anyway at least foo_uie_tabs, the sidebar, maybe a horizontal sidebar, possibly horizontal & vertical splitter panels would come into this category (if this was implemented), maybe it would be worth it putting them under their own category, but I don't know what it should be called. Its probably not worth thinking about this now anyway, since there is only one panel in that category for now.

Otherwise I don't think we need any other categories? It probably depends on how many panels pop up, I mean if there ends up like 20 under panels I think we'd need new categories then.
.

question about ui_extension API

Reply #24
Quote
I made a couple other minor changes since the above version of the api, I may make a couple more whilst I implement it. I will hopefully be done by the weekend, I guess I will upload the new sdk so you can review it. So start commentting now if you want, or wait until later.
Well, I think I might be able to find something else to do on the weekend, if I try (in case you're not finished until then).

Quote
Either way, it would be useful to merge your doxygen comments into my distribution.
Agreed. If you merge them, could you add \todo markers to new or modified stuff, so I know which parts need to be worked?

Quote
Do you want your helpers in there as well?
Would be nice.  I had the idea to create another, similar helper class that additionally supports docking and undocking, though I don't consider that top priority. Hm, docking might be tricky (more like currently impossible), since it would have to find instances of ui_extensions that double as hosts.

Quote
Anyway at least foo_uie_tabs, the sidebar, maybe a horizontal sidebar, possibly horizontal & vertical splitter panels would come into this category (if this was implemented), maybe it would be worth it putting them under their own category, but I don't know what it should be called.
Let's call it "Layout".

Quote
Otherwise I don't think we need any other categories? It probably depends on how many panels pop up, I mean if there ends up like 20 under panels I think we'd need new categories then.
Sounds reasonable.