yaP - yet another Portablizer

[tproli]

But would make it more GPL!

(whatever that means IRL)

[webfork]

tproli,

Going GPL doesn't make your launcher more popular. Your code, you property, you do what you want. Simple!

But would make it more GPL!

(whatever that means IRL)

Making the code open helps on several levels including trust, code assistance, bug fixes, and longevity. Opening your code and attaching a "do whatever you want" license is fine, but there have been a number of historical cases where a group will pick up some code, tweak it, and make previous versions of the software incompatible or less-compatible than theirs. The share-and-share alike idea behind the GPL helps ensure the code remains open and sort of levels the playing field.

In community projects, one of the biggest problems is trying to give people a sense of ownership of the project so they treat it like their own. The GPL seems to inspire this more often than others.

[guinness]

I had a spelling in mistake in my previous post.

There is misconception that by going open source will invoke an array of bug fixes and help with the code, this isn't true I'm afraid. Most users don't have a clue about licensing, so they don't really care one way or the other.

[Midas]

Most users don't have a clue about licensing, so they don't really care one way or the other.

The Future does...

Seriously, I can envision situations where opening the source might make more difficult for a single developer to manage the development process, and that's why I'm OK when he decides to keep his code proprietary -- his game, his rules.

What concerns me is that, once his personal engagement fizzles, the natural course of action should be to open source it, so others may take up where he left without having to 're-invent the wheel' (or, if it draws attention enough, reverse engineer it -- as Agent Smith would say: "It's inevitable, Mr. Neo!"), thus granting the user base with reasonable expectation of posterior program adaptation and/or evolution, instead of the slow descent into obsolescence, irrelevance and oblivion we so often witness...

WikidPad history serves as a superb positive example that immediately springs to mind, supporting a firm belief that code as speech should trump code as commodity -- as my lingering around TPFC would illustrate...

[SYSTEM]

There is misconception that by going open source will invoke an array of bug fixes and help with the code, this isn't true I'm afraid.

Confirmed.

For developers, the main advantage of opening the source is ability to use open source hosting sites such as SourceForge, Google Code and GitHub.

Most users don't have a clue about licensing, so they don't really care one way or the other.

The Future does...

Seriously, I can envision situations where opening the source might make more difficult for a single developer to manage the development process, and that's why I'm OK when he decides to keep his code proprietary -- his game, his rules.

What concerns me is that, once his personal engagement fizzles, the natural course of action should be to open source it, so others may take up where he left without having to 're-invent the wheel' (or, if it draws attention enough, reverse engineer it -- as Agent Smith would say: "It's inevitable, Mr. Neo!"), thus granting the user base with reasonable expectation of posterior program adaptation and/or evolution, instead of the slow descent into obsolescence, irrelevance and oblivion we so often witness...

WikidPad history serves as a superb positive example that immediately springs to mind, supporting a firm belief that code as speech should trump code as commodity -- as my lingering around TPFC would illustrate...

I think even more important is that in closed source projects whoever owns the project can make any decisions (such as remove features and change the user interface without any reason). In open source projects attempts to do so will lead to forks. LibreOffice is probably the most famous example.

[guinness]

You can tell from the comments posted here, who is a developer and who isn't.

[Midas]

I'm sharing here a (basic) yaP launcher I recently put together, after I was kind of forced to use Ziin's Mail Exporter, a simple Outlook Express/DBX message extractor:

http://www.filedropper.com/mailexporter10-yap

Extract archive, go to 'application' URL and download, UniExtract, copy files in '{app}' dir, rename 'mailex.exe' to 'mailex.main'...

Mail Exporter homepage: http://ziin.pl/en/mail_exporter

[tproli]

Great, thanks! Do you mind if I add it to the yaP site?

Btw, the yaP version in your download is 0.27 and the latest is 0.31.

[Midas]

Great, thanks! Do you mind if I add it to the yaP site?

• Of course not, go right ahead, no need to ask in the future -- you provided a free tool, I provide what little I can.

Btw, the yaP version in your download is 0.27 and the latest is 0.31.

• I noticed that afterwards, when I consulted yaP's page to dispel some doubt I had; already updated.

[Napiophelios]

So you have a nice homepage for yap and do regular bugfixes and updates,
Its just as reliable and handy as jauntePE for making on the fly portables
...why no entry in the TPFC DB?

[tproli]

yaP is not such a heavyweight player like JPE or others but yes, listing it here would be nice. It is still in beta and when it reaches a more bug-free state I will add it here too.

[Midas]

Another day, another app yaPed...

Kanu kindly posted a comment (http://www.portablefreeware.com/?id=418#comment24658) disclosing the (meager) requirements to make Disk Cleaner fully portable, so here it is:

http://www.filedropper.com/diskcleaner181795-yap

[tproli]

Thanks, uploaded to yaP site too. I was used Disk Cleaner a lot years ago but an older version. It ran on every Win startup to clean up things.

Interesting solution you are using here - moving dcsettings.ini out from the App directory. I guess I would have left it in the App, never thought of this "trick" to separate the application from its settings. Interestingly it works without the "{EXEPATH}\" but that is fully unintentional.

[Midas]

Interesting solution you are using here - moving dcsettings.ini out from the App directory. I guess I would have left it in the App, never thought of this "trick" to separate the application from its settings. Interestingly it works without the "{EXEPATH}\" but that is fully unintentional.

Thanks. The motivation here is that, as per Kanu instructions, 'dcsettings.ini' has to be present on first launch or else Disk Clean will default to %APPDATA%...

[tproli]

I see. Perhaps yaP needs a new feature for [FILES]: "create"? That would create a new empty file with a given name.

Currently the downloadable yaP configs cannot contain any extra files.

In my quick test no directory was created even if there was no dcsettings.ini (not in the App dir and not in the launcher root, using yaP-ped DiskCleanerPortable).