(forgive the long post, it's a big concept)
Okay, so I've built some very rudimentary plug in framework into the latest experimental version of geek.menu, and pulled out background picture setting from the main code, and implemented it as a plugin. I'm hoping that this framework (or at least a much improved version of it) will work it's way in to a future version of PAM, assuming we ever get past the "hey would you like to help out with future versions?" stage of cooperation.
The idea is that the menu itself ends up stripped down and bare bones, and people can pick and choose the features that make sense for them. So if you like the encryption stuff, but don't want windows integration features, you can do that. Plus it will eventually allow people to design all sorts of cool stuff I've never even thought of, and open up development outside of the Delphi community.
I'd like some feedback on the way I've got this set up at the moment.
Plugin Types:
(one plugin could conceivably be more than one (or even all) of these)
- execute before startup - for critical components that might do things like mount encrypted document paths that need to be executed before the menu can start.
- threaded startup - things like auto running applications have no place in the main thread of the menu startup, so they can run in a different thread while the menu moves on to other things
- non threaded startup - something that the menu requires to complete executing before finishing loading.
- App Right Click plugins - a plugin that adds a right click menu item to a listed application.
- shutdown plugins - plugins that have some tasks to perform at menu shutdown
- form interface plugins - plugins that add edit boxes and buttons to the menu itself - i'm not really sure how I'll implement this, but it's been on my todo list forever.
- plugins with configuration dialogs - will be presented on the "options" menu under a "plugins" item. If a plugin requires initial configuration, it can pop this dialog box up the first time it is run.
Passing Data:
One of the challenges with this was how to get data passed out from the menu (for example, document folder location or other items that might be localized. COM under Windows is far from being portable, so I ended up taking a stroll down memory lane with a DDE Server in the menu.
Beyond the path to the menu application, the .ini file, the current locale, the data directory and the various document directories (Pictures, videos, etc), I'd like to have some suggestions for other data that could be called from this stack.
Thanks for any input,
-xopher
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
I'd prioritize the "form interface plugins" implementation lowest, but that's just me. :-) I presume it'd be for search boxes and the like?
Me likey. -hea
I'm pretty sure my UP ME app does a few of them, but I don't really think plugins are viable, I think John wants it to be very customizable. If you've seen, the new 1.1 release allows you not to have a personal icon at all.
It is a big concept, but I think it would require a lot of downloading, I mean, why not add a few kb to the menu so that we don't have to download a lot?
I like geek.menu, but on my slow backup drive, it's kinda slow and buggy. (I really needed that autorun feature, so I implemented a new startportableapps.exe...
Insert original signature here with Greasemonkey Script.
Slow and buggy? Didn't encounter it.
I can count 10 seconds between the time I plug in the drive and menu starts.
Insert original signature here with Greasemonkey Script.
In my testing, with none of the advanced features turned on, geek.menu outperforms PAM, especially if "Accelerate Menu by loading apps from file" is checked. Without that, checking the categories of large numbers of apps does take a while.
Most of the performance gains are achieved by isolating non-critical functions (wallpaper, etc) in separate threads, which is why the plugin architectures supports this as well.
Of course, using TrueCrypt encryption slows geek.menu down significantly, but that will always be the cost of software based encryption.
I did turn on the accelerate menu thing, and I had only autorun as a special feature.
Oh, so that's what. But in that case, why not just have a seperate EXE that handles all the non-critical functions?
Insert original signature here with Greasemonkey Script.
Well, that's essentially what a plugin is, it's just compiled as a dll.
Only the menu has more control over when it calls a plugin, and the plugin can interact directly with the menu (add right click menus, etc). The plugin support can also help improve regular applications as well- for example, the launcher for a music player can use DDE to pull the folder location for the localized "Music" folder, and set that as the default path.
Essentially, if we can properly build a robust plugin architecture, there won't be a need for forks and mods (assuming the menu proper includes critical features like categories, etc)- people looking for additional features can get them through a plugin, and the performance, size, and memory costs of the additional features won't impact those who don't need the plugin.
For example, I use portableApps to acheive the same desktop at home and at work- I use it with a fast PC and am looking for a high degree of desktop integration, which is why geek.Menu has font support, creates send-to shortcuts, modifies the system path, changes the places bar, etc. This is fantastic for me, but for someone who simply wants to be able to use portable Firefox, this is extreme overkill. So if Desktop integration becomes a plugin, then the efficiency of the menu overall is improved, while continuing to provide advanced features for those who want them.
Different bundles of the menu can be distributed targeting different audiences, etc. Additionally, it will allow developers to improve the menu without writing in Delphi, which should increase the potential developer pool significantly, as Delphi is a relatively un-popular environment. Instead, any language that supports creating stand-alone dlls can improve the menu.
would they be in PAF, or just in the app folder of the menu?
I would consider David's DeskLinkz and my UP ME apps plugins, there's not really any other way to describe them.
Hm...
Maybe then I could write the app manager I wanted to write in AHK instead of Delphi!!!
Insert original signature here with Greasemonkey Script.
sure
This is huge, but can you implement different menu themeing styles based on the plugins? Probably not, but I just thought I'd ask.
Too many lonely hearts in the real world
Too many bridges you can burn
Too many tables you can't turn
Don't wanna live my life in the real world
you mean kinda like MrElchBlau's 2-click theme.
I seriously don't really like the plugin idea unlesss if there's so man
@Maggotb0y: Do you happen to know how the menu finds all the exe's? I can't seem to understand what part in the menu does what...
Insert original signature here with Greasemonkey Script.
I think part of your thought got cut off there- "unless there's so man"?
Are you asking how the menu looks for the executables to display? In PAM (and geek.menu with "accelerate..." unchecked) there is a findfirst.. findnext bit of code that basically searches the drive for any executables within folders inside of the "PortableApps" path. This is the bit that takes forever on a slower drive.
Geek.Menu addresses this with the "accelerate menu" checkbox, which essentially does a one time scan of that folder and then loads those apps from a file- when you refresh app icons, it goes back through that scan.
That's the eventual plan.
But I won't be doing anything with theming until I have some idea what the theming framework for 1.5 will be- John's still keeping his cards tight against his chest on this right now.