BrandonTools

I have a suggestion for the start gadgets. It would be nice to be able to create a local html file to be displayed in the gadget, much like the way you can create custom scripts in search startlets. This file could use javascript to fetch data from other websites and display it in the start menu. This would have the advantage of being able to create gadgets specifically for start++, instead of relying on externally hosted iphone apps that do not always display well. Also it would open the door to some fun possibilities like having javascript games or the like in the start menu.

I think it would probably be possible already to reference local html files, however this would not work with the nice packaging functionality you currently have.

Leddt - good suggestion.  That's actually been the plan all along :)  I just need to work out the right packaging format (probably using a ZIP container with a manifest, like the Sidebar gadgets), and actually code it up.  I also need to figure out what would be useful to expose via Window.external, and whether I want to scrap the existing "Search Startlet" support in favor of just providing Start Gadgets (local ones) to access search results.  But yes, local gadgets with a useful package format are part of the 1.0 plan.

Nice. My suggestion would be to keep the search startlets as I find them extremely useful. Its a very simple, no hassle way to script the search index. I'm addicted to my playr command 

Maybe at some point you could refactor the app to use a plugin architecture, that would allow you to separate the different kinds of commands that you have right now (commands, gadgets, search). Plus you could release the interface for the plugins and allow other people to extend your app. You could then concentrate on solidifying the existing features, and let the community build new features. I think the best thing would then be to open source the plugins, allowing everyone to see how they were made.

Also, I just want to make sure that you noticed my bug report on the previous page about the zoom factor setting. I have a feeling this could be part of the reason why some people get extremely large text in the gadgets.

Because I have a wide monitor, I put my taskbar vertically on the right side of the screen.

This seems to upset the display of most of the Start++ gadgets (such as calc and g).    (I'm using Start++ 0.7.5)

hhoppe:

Because I have a wide monitor, I put my taskbar vertically on the right side of the screen.

This seems to upset the display of most of the Start++ gadgets (such as calc and g).    (I'm using Start++ 0.7.5)

Oh strange.  Works fine on every other side of the screen.  Added to my list to investigate.

atomi:

Installing  the VC++ libs fixed "the value cannot be null" issue for me.

Anyway, I don't like the new release, can you provide the 0.6 release for download?

For some reason everytime I run a startlet, when running from the start menu even though Start++ is not running is enabled, Start++ opens the Start++ configuration dialogue instead of running the command.

It's frustrating not to be able to revert back - especially when I won't be using any gadgets or search startlets.

Actually, on second look - I am not able to reproduce this problem.  I closed Start++ (both with the Run In Background option enabled, or disabled), and ran the "g" command.  The configuration dialog doesn't show, and the startlet runs normally.

Seems like something else may be wrong with your configuration.  When you type the command - what is the top (selected) entry in your Start menu?

puntor:

found a bug, try erasing everything from the search box after searched anything(i searched weather 00961)the start menu goes blank instead of showing your recent programs and pinned programs

Oh interesting, I couldn't reproduce this at first.  But it appears to only happen if you click the "clear" button (the X), not if you use the Backspace key, or select the text and delete it.  Added to known issues list.

Brandon:

Seems like something else may be wrong with your configuration.  When you type the command - what is the top (selected) entry in your Start menu?

See. http://img454.imageshack.us/img454/3206/startut6.jpg

 

(1.) Shows the command 'chillout' which should run winamp with the argument as shown.
Instead, it runs the start++ configuration dialogue (the same occurs when using notepad as the command with an argument for the hosts file for example).

(2.) Shows another problem. Apparently the startlet command only runs if it does not match a current indexed keyword.

I liked the way start++ worked before all these new features were added (now requiring even extra libraries installed).
I agree very much with leddt when he suggests:

leddt:

Nice. My suggestion would be to keep the search startlets as I find them extremely useful. Its a very simple, no hassle way to script the search index. I'm addicted to my playr command Wink

Maybe at some point you could refactor the app to use a plugin architecture, that would allow you to separate the different kinds of commands that you have right now (commands, gadgets, search). Plus you could release the interface for the plugins and allow other people to extend your app. You could then concentrate on solidifying the existing features, and let the community build new features. I think the best thing would then be to open source the plugins, allowing everyone to see how they were made.

 

atomi:

Brandon:

Seems like something else may be wrong with your configuration.  When you type the command - what is the top (selected) entry in your Start menu?

See. http://img454.imageshack.us/img454/3206/startut6.jpg

(1.) Shows the command 'chillout' which should run winamp with the argument as shown.
Instead, it runs the start++ configuration dialogue (the same occurs when using notepad as the command with an argument for the hosts file for example).

Very strange - that should be working.  Is the path to Winamp.exe correct?  Does it show the same behavior for other commands? (like "g", etc?)

(2.) Shows another problem. Apparently the startlet command only runs if it does not match a current indexed keyword.

Yes, that's because you don't have Start++ running in the background.  It's a known issue with the old, "passive" hooking mechanism.  Any program in your start menu can pre-empt the Start++ shortcuts if it's a better match for your query (which happens most often with one letter triggers). 

I can't do anything about it if Start++ isn't running, because of the nature of how the Start Menu works.  However, that *only* happens if Start++ is not running in the background, which is something I'm less and less willing to support because of this very issue.  If Start++ is running, it will always match your command (unless there's a bug of some kind, of course). 

The only other option is to actually inject a DLL into Explorer all the time, containing the same code that currently exists in the seperate process.  There's no good reason to do that, versus what I'm currently doing (very very tiny, fool-proof DLL injected into Explorer, only when Start++.exe is running).  For one, it would require that Start++.exe be rewritten in native C++ code.  Second, it would mean that a bug or issue with Start++ could destabilize Explorer.  Neither of those is worth trading for the very very tiny overhead of running a seperate process.

I liked the way start++ worked before all these new features were added (now requiring even extra libraries installed).

The new libraries shouldn't be required seperately, I just didn't have time before my trip to add the DLLs to the installer.  Every single application written in C++ requires those, and Start++ is now partially written in C++.  I'll fix that very soon, so you won't know the difference.

Brandon:

Very strange - that should be working.  Is the path to Winamp.exe correct?  Does it show the same behavior for other commands? (like "g", etc?)

Not that I have seen. The Start++ configuration dialogue appears when a non-browser application and argument are used for the startlet command - with correct paths mind you.

In the end I guess this doesn't matter, as you've made clear you're not likely to continue support for startlets without the start++.exe background process. I just won't be using Start++ any longer.

atomi:

Brandon:

Very strange - that should be working.  Is the path to Winamp.exe correct?  Does it show the same behavior for other commands? (like "g", etc?)

Not that I have seen. The Start++ configuration dialogue appears when a non-browser application and argument are used for the startlet command - with correct paths mind you.

Hmm, seems I am able to reproduce the problem after all.  I'll debug it the next time I'm working on Start++, should be able to fix it.  It almost certainly affects command-line invocation as well.

In the end I guess this doesn't matter, as you've made clear you're not likely to continue support for startlets without the start++.exe background process. I just won't be using Start++ any longer.

Sorry to hear that.  Any particular reason you don't want it running in the tray?

Brandon:

Any particular reason you don't want it running in the tray?

Nothing in particular, but possibly, one or more of the same reasons the feature to use startlettes without the start++.exe background process was added in the first place.

atomi:

Brandon:

Any particular reason you don't want it running in the tray?

Nothing in particular, but possibly, one or more of the same reasons the feature to use startlettes without the start++.exe background process was added in the first place.

 That feature wasn't added, though.  That was the original functionality of Start++ (an editor for shortcuts that could be promoted to the Start Menu).  When I found the time to implement a real Start Menu hook, that functionality became largely obsolete.  I left it in place for a while because the new hook wasn't competely reliable (could lose track of the Start Menu) in the 0.6 versions of Start++.  But starting in 0.7 it no longer has that problem, and as far as I've found will always work.  Thus having the old fallback mechanism isn't really necessary, and will probably be removed now that the new mechanism is more proven.

Brandon:

That was the original functionality of Start++ (an editor for shortcuts that could be promoted to the Start Menu).

How about you release the code for that original functionality? I'm sure I'm not the only one who wouldn't mind rebuilding it.
 

Just to let you know, the 0.7.7 update didn't fix the zoom factor problem on my computer.

The app will correctly LOAD "0.8", but will SAVE "0,8" and will later get an error when trying to load "0,8".

Also, even after a successful load of the "0.8" value, the zoom factor is still not applied to the gadget when it's displayed.

Hope that helps, keep it up!