Skip to main content
Topic: ICC (Read 10886 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ICC

I like to start a discussion of implementing some inter component communication framework.  If foobar already allows this then please enlighten me.

Otherwise, what I'd be interested in is a way to utilize other installed components.

For example,

CuriOus_George as a nice one foo_playlistfind I believe it is called.

Aero just released a first pass of foo_bookmark.

I'd like to be able to use both of these directly from foo_wsgui (even though I seem to unknowingly crash foo_bookbark  ) via some programming interface.

1.  For playlist find I'd like to be able to catch keystrokes myself then call "search" with the string.  Playlist find would do its thing.
2.  For bookmark I'd like to be able to add a bookmark directly from foo_wsgui.

So, the point is I'd like to have a way that all of these components could work together.

The only way I can think to do that now is with some hotkeys assigned to the actions then passing those to foobar when pressed in wsgui.  Even that only really works for case 2.  Since I'm doing a front end engine something more robust would be useful.

Ideas anyone?

ICC

Reply #1
Well, 3rd party plugin creators can create services and register them.  Other plugins can then enumerate these services.  foo_history does just that.

P.S.  There's no way to "tap into" the playlist searching, though, so far as I know.

ICC

Reply #2
Quote
Well, 3rd party plugin creators can create services and register them.  Other plugins can then enumerate these services.  foo_history does just that.

P.S.  There's no way to "tap into" the playlist searching, though, so far as I know.

I wanted to tap in to your searching  - is foo_playlistfind a service?

How does one enumerate the services available and the methods they support?

ICC

Reply #3
I believe the appropriate method is service_factory_base::create_enum().  I don't have the SDK handy.  But basically, you can enumerate anything.  You can enumerate the contextmenu items.  You can enumerate the components menu items, etc.  To tap into anything more than the SDK provides (e.g. if I created some nifty searching plugin with great service capabilities), you would need some sort of API (e.g. I would need to provide an API for my DLL, and register the appropriate service).

How exactly did you want to tap into foo_playlistfind?  You should be able to pop up the window (by manually calling the components menu item), I believe, but I'm not sure if that's what you're wanting.

ICC

Reply #4
Quote
I believe the appropriate method is service_factory_base::create_enum().  I don't have the SDK handy.  But basically, you can enumerate anything.  You can enumerate the contextmenu items.  You can enumerate the components menu items, etc.  To tap into anything more than the SDK provides (e.g. if I created some nifty searching plugin with great service capabilities), you would need some sort of API (e.g. I would need to provide an API for my DLL, and register the appropriate service).

How exactly did you want to tap into foo_playlistfind?  You should be able to pop up the window (by manually calling the components menu item), I believe, but I'm not sure if that's what you're wanting.

Thanks for the info.

For foo_playlistfind I'd might like to provide an input box in wsgui and just pass the search string to foo_playlistfind.  ie. bypass your edit box window but still get the same outcome (the first match is highlighted in the playlist).  Your plugin is a good candidate for a service since your UI isn't really needed wrt to foo_wsgui, foo_ufts, or even your own foo_minibar could use it as a "service"

Same idea with a book mark plugin.  I might want to provide a button on wsgui that adds the current song to the bookmarks without using the foo_bookmark UI.

ICC

Reply #5
I'm supposed to be churning out a new version of foo_minibar soon.  (I was supposed to put out a new version this past weekend, but I didn't do any work on it.)  I'll see about adding a proper service, so you can just pass your own search string, rather than using my input box.

ICC

Reply #6
Quote
I'm supposed to be churning out a new version of foo_minibar soon.  (I was supposed to put out a new version this past weekend, but I didn't do any work on it.)  I'll see about adding a proper service, so you can just pass your own search string, rather than using my input box.

That would be cool as I think foo_playlistfind is a good compliment to the built in search.

Oh, speaking of that another suggestion for foo_playlistfind.

I read a post by someone asking you to make it only search on return key instead of per character.

Another option that I've used before that I think works well (and would prob. how I will implement it once you make a service  ) is to reset a timer on each key press and delay the search until the timer expires.  Fast keying keeps resetting the timer so that you don't search on the first letter typed unless you want to (ie. type a single char and nothingn else for say 250 ms or something).  At the same time you don't have to wait for a carriage return either.  This works well for backspacing too and it makes the search a little more responsive since you weed out unneeded intermediate searches.

Just an idea.

ICC

Reply #7
Not a bad idea.  It could work for something like this.  (It wouldn't work very well for something like foo_shizzle, though.)

ICC

Reply #8
Quote
Not a bad idea.  It could work for something like this.  (It wouldn't work very well for something like foo_shizzle, though.)

Are you refering to making the interface more responsive? Well, searching in the background surely helps - like in foo_dbsearch, though the code that synchronizes results with the gui is a bit ... messy right now. Reimplementing this with a proper model-view-controller architecture will surely help...

Given a specific plugin, providing new services is imho the best way to let other plugins use its features. Of course the interface needs to be public (e.g. available in an include file) as well as the guid (which is located in a .cpp file and must be linked into any plugins that want to use it). I suggest to use a common directory to put these files into. I already did this for foo_history (the directory is called "3rd_party" there), and foo_dbsearch will have this as well some time in the future. I plan to make the search core with all it's features available and - to some degree - the gui. Unfortunately I don't have much time at the moment to work on fb2k plugins

ICC

Reply #9
That's what I plan to do (with the service interface).

I never implemented background searching in foo_shizzle because I was getting deadlocks.  I think I know now where the deadlocks were occuring, but I also lost a huge chunk of the foo_shizzle code, so I just haven't felt like messing with it.  For a plugin like playlistfind, though, searching in the background is just overkill and I refuse to mess with it.

ICC

Reply #10
Can someone post a code example of getting/using a 3rd party component service (like foo_history) from another component?

EDIT

And what happens if your component is "linked" to to 3rd party service and that component is gone or doesn't load?  Also, is there a mechanism for making sure the linked interface matches the actual service interface (like if new versions come out).  Sorta like how COM does it in that you are guaranteed a certain interface regardless of versions, etc.

/EDIT

 

ICC

Reply #11
Interface types are identified by GUIDs (see: static GUID get_class_guid() everywhere). If a third party developer publishes their custom interfaces, its their own responsibility not to change those interfaces between different versions of the component (and if they need to be changed, changing the GUID is recommended way to prevent people from getting wrong interface pointers). If particular interface isn't present, attempt to enumerate it will not return any objects.
There is code enumerating/using services all over SDK (eg. sending messages to console, opening files, opening inputs, etc), just open your eyes and read it instead of asking.

ICC

Reply #12
Quote
Interface types are identified by GUIDs (see: static GUID get_class_guid() everywhere). If a third party developer publishes their custom interfaces, its their own responsibility not to change those interfaces between different versions of the component (and if they need to be changed, changing the GUID is recommended way to prevent people from getting wrong interface pointers). If particular interface isn't present, attempt to enumerate it will not return any objects.
There is code enumerating/using services all over SDK (eg. sending messages to console, opening files, opening inputs, etc), just open your eyes and read it instead of asking.

Yeah, I've seen that I just wondered if the procedure was any different for a third party component that isn't part of the SDK  - I'll figure it out.

Sorry to bother you with my questions.

ICC

Reply #13
Well, if third parties provide their own service types, it's a good habit to provide some kind helper code for enumerating them too.
Otherwise, standard service_enum_t methods work everywhere (no reasons why they wouldn't), it's just that enumerating job can be simplified with some services - eg. enumerate only those object that match certain criteria, or simple get() function returning pointer to a single static instance of the object (like with metadb).

ICC

Reply #14
Yeah, helpful!
Good good study, day day up, :)
[span style=\'color:red\']The superman is the meaning of the earth.
Let your will say: the superman shall be the meaning of the earth![/span]

ICC

Reply #15
danZ, foo_playlistfind has a very simple interface now.  It should get fleshed out soon, but it can do basic playlist searching now.

There's an extremely trivial example in the "examples" folder.

http://gelaed.com/resources/cplusplus/foo_...laylistfind.zip
http://gelaed.com/resources/cplusplus/foo_...istfind-src.zip

P.S. The stuff you need to interact with the plugin is in the Interfaces folder. 

ICC

Reply #16
Quote
danZ, foo_playlistfind has a very simple interface now.  It should get fleshed out soon, but it can do basic playlist searching now.

There's an extremely trivial example in the "examples" folder.

http://gelaed.com/resources/cplusplus/foo_...laylistfind.zip
http://gelaed.com/resources/cplusplus/foo_...istfind-src.zip

P.S. The stuff you need to interact with the plugin is in the Interfaces folder. 

Cool, I'll check it out.  Thanks.

The playlistfind-src.zip doesn't have an Interfaces folder.  It did have an Examples folder so I have a good idea how the service will work.  I better work on some kind of keyboard input field for foo_wsgui now that I don't have my keyboard handling fecked up.

ICC

Reply #17
foo_history does contain an example how to use the history service - the GUI. Just have a look at foo_history.cpp, where it is implemented. history_i.cpp contains the implementation for the history service; you actually shouldn't need to worry about it.

ICC

Reply #18
Quote
foo_history does contain an example how to use the history service - the GUI. Just have a look at foo_history.cpp, where it is implemented. history_i.cpp contains the implementation for the history service; you actually shouldn't need to worry about it.

So I would inlcude foo_history.h in my build and then simply enum the history service and use it?

ICC

Reply #19
Quote
The playlistfind-src.zip doesn't have an Interfaces folder. It did have an Examples folder so I have a good idea how the service will work


Did you leave out some stuff from the .zip file?

ICC

Reply #20
Hmm.  Apparently I did leave it out of the folder.  Hrmf.  I'll get a new bersion up pronto.  I'm fixing some bugs in foo_playlistfind right now.



ICC

Reply #23
Don't do too much work with it, though.  I'll be putting out a new version with some new interface features sometime today. 

ICC

Reply #24
Weird problem.

I add the playlist interface to my build.

I'm calling the search, getting what look like correct results but the playlist isn't updating.  Basically, I can't set the focus item from my component.

I tried setting the focus from the iniquit object and that worked so I suspect some thread issue or something.

I noticed you had a

extern playlist_oper * g_oper = NULL;

which you set/release in the initquit.  Did you have a problem like what I describe?

I tried replicating the same thing

a global called from my message loop thread but it still didn't work.

my relevant code is just

      int findPos = global_playlist_find::get()->search(m_Hot[Title1].GetText(),g_play_oper->get_focus());
      g_play_oper->set_focus_sel(findPos);


findPos seems to be correct (the search is working).

EDIT

Otherwise, very simple to add and use and I think this compoent service sharing could be very powerful and beneficial overall.  Especially for a gui front end like wsgui.  Thanks for creating the interface.

/EDIT

Ideas?

 
SimplePortal 1.0.0 RC1 © 2008-2019