Power users should be able to let a scrept execute before and after Picasa is started from PicasaStarter

[GoogleCodeExporter]

search for Local Picasa Imported pictures/videos 

    In Picasa/Options, General, specify imported pictures location, e.g.: 
        My Pictures\Picasa\Imported
    We will get this path from the registry

    will COPY/MOVE files from local imported folder to _Imported subfolder under set PICPATH variable defined in RunPicasa.cmd

Original issue reported on code.google.com by bkea...@keadle.net on 5 Nov 2011 at 3:58

Attachments:

• LocalPicasaImport.cmd

[GoogleCodeExporter]

I'm sorry for being dense Bryan, Could you describe this issue a little more 
clearly for me? What is the function you want to add to the PicasaStarter 
program?
Are you wanting to be able to set the Imported pictures location from PS?
Or do you want PS to copy the pictures from a defined location into Picasa's 
picture folder? This seems like an Ideal thing for a button.

Original comment by earlb...@gmail.com on 5 Nov 2011 at 6:35

[GoogleCodeExporter]

thinking of my wife...but common task anyway...
when plugging in a digital camera to unload pictures/video, Picasa would be the 
(preferred) application to import the photos.  However, this would launch 
Picasa using the local database (and not the shared database that 
RunPicasa.cmd/PicasaStarter would set up).  So, I'd "allow* her to unload the 
camera to her local computer, but when RunPicasa.cmd/PicasaStarter launches 
Picasa, I'd want to "import" the pictures in her local profile imported folders 
folder into our "shared album".

Make sense?

Original comment by bkea...@keadle.net on 5 Nov 2011 at 8:37

[GoogleCodeExporter]

...and yes, you're right, that could be button, but I prefer it to be a 
scripted process so it happens automatically.  This is what 
LocalPicasaImport.cmd called from RunPicasa.cmd does.  That would be a cool 
Picasa "button" if you could configure it to launch at startup, like the old 
DOS autoexec.bat.  If PS provides the functionality of RunPicasa.cmd (making it 
obsolete), then I'm thinking about how to be able to do other 
"Autoexec.bat"-type things prior to launching Picasa.  Now, I could create a 
new wrapper .cmd like RunPicasa that would launch PS, but just a thought for PS 
to be the all-in-one Picasa-launcher tool.  

So in summary, and AUTOEXEC.PS (get it?) for PicasaStarter!
:-)

Original comment by bkea...@keadle.net on 5 Nov 2011 at 8:46

[GoogleCodeExporter]

Ok, I see what you mean. Some kind of a file that PS runs automatically if it 
is there, or if there is a pointer for it in PS.

As far as the import thing goes though, If your Picasa is running through 
PicasaStarter  when you plug in your camera and you import, the import will go 
to the Proper pictures folder directly. What picasa thinks of as it's database 
folders are mapped to the normal user locations for Picasa, so It doesn't know 
anything is going on.

Now if you use an external thing or explorer to import the pictures, then you 
would have to tell Picasa's import command to use the import folder as it's 
source, or copy the pictures directly. So that is not very automatic.

Original comment by earlb...@gmail.com on 5 Nov 2011 at 9:02

[GoogleCodeExporter]

Correct - if Picasa is running through PicasaStarter, then the environment is 
set up and the imported folders will go in the proper place.  But that's not 
very likely.  One wouldn't want a participating computer to "stay in PS/Picasa" 
if it's not actively being worked on since it will prevent other participating 
computers from getting in.  So, use PS to launch Picasa - do your Picasa work, 
then get out.

Though I could "dictate" that before you unload photos, launch PicasaStarter 
first, then import photos from the camera - but that's an extra step, and not 
likely to be consistently followed.

Instead, she/I/we can just import from the camera without thought of needing PS 
to be launched first, and let the "unloaded camera photos/videos" queue up in 
imported location on the local computer.  Then, when PS is launched, then any 
locally-stored imported photos/videos will automatically be moved to the shared 
photo location.

I should clarify - this is the autorun process of plugging in a camera or media 
card - you know that dialog about what you want action you want to take.  I 
would specify to import photos using Picasa, and it would do its thing. 

So the process:
- plug camera/media/etc. into the computer, Autorun prompts what to do
- select Picasa to import pictures
- Picasa unloads the camera/media to local Picasa Import folder
( one wouldn't spend much time manipulating or otherwise working with these 
images if they are destined to the shared location) - but perhaps delete 
imported content not intended to keep (garbage pictures)
- close Picasa - task of unloading pictures/video completed.

When ready to work on/view shared photos:
- launch PicasaStarter
- prior to launching Picasa, any imported photos/videos found on local drive, 
optionally move to (established) shared location

- to then move the imported folders into the shared location

Original comment by bkea...@keadle.net on 5 Nov 2011 at 9:26

[GoogleCodeExporter]

And yes, 
"Ok, I see what you mean. Some kind of a file that PS runs automatically if it 
is there, or if there is a pointer for it in PS."

That would do the trick - I could call my LocalPicasaImport.cmd.

In fact, I could have a .\bin\PrePicasa.cmd configured to do tasks prior to 
launching Picasa (like LocalPicasaImport, logging, whatever) - but after PS has 
established my defined shared environment.  In fact, if we offering some 
pre-processing ability, how about some post-processing ability as well, call 
out to .\bin\PostPicasa.cmd to do my own post processing after exiting Picasa, 
but before returning to PicasaStarter...like my script to remove empty 
directories, for example.

Thus:
RunPicasa.cmd/PicasStarter Environment setup >> PreProcessing >> Picasa.exe >> 
PostProcessing >> environment teardown >> PicasaStarter >> Exit

Original comment by bkea...@keadle.net on 5 Nov 2011 at 9:32

[GoogleCodeExporter]

Sounds to me like it might be too complicated for the normal user, so would we 
hide it?  Explain it well enough? Put in an advanced mode? 

PS has always aimed for the normal user, and RunPicasa was for the 
knowledgeable user who had special needs. Pieter always tried to keep it 
simple. 

Even putting RP into PS is a bit of a stretch, for the target audience.

Original comment by earlb...@gmail.com on 5 Nov 2011 at 10:21

[GoogleCodeExporter]

Yep, I completely agree with both of you... This was another very constructive 
chat ;-).

It started with a very specific workflow, that is probably not very reusable 
for a lot of people... and evoluated towards a generic feature that can be used 
for a lot of things for power users.

And I agree 100% that it is nice to be able to do such advanced things, but it 
shouldn't make PicasaStarter more difficult to use for the average user.

So I just build in this: 
   - if you put a file "Pre_RunPicasa.bat" in the same directory as PicasaStarter.exe, it is executed just before Picasa is run when pushing the "Run Picasa" button.
   - if you put a file "Post_RunPicasa.bat" there it is executed just after Picasa is closed.

Do you think that will do the trick?

Original comment by pieter.r...@gmail.com on 5 Nov 2011 at 11:56

• Changed state: Implemented
• Added labels: Milestone-Release2.0.0

[GoogleCodeExporter]

Hit "Save changes" too fast, forgot the conclusion ;-):

This gives the opportunity for power users to hook in on this spot in 
PicasaStarter, is invisible for the average user, and was only 10 minutes of 
work (and probably 2 hours of bugfixing afterwards, but yeah...)

Original comment by pieter.r...@gmail.com on 6 Nov 2011 at 12:01

[GoogleCodeExporter]

Hi Pieter!
Yes, that will work fine for me, It is invisible to normal users, and gives a 
lot of control to power users, as long as we document it when we get to the 
release stage.

It'll be even more useful if/when we figure out the map to another directory 
(RunPicasa) implementation.
Earl

Original comment by earlb...@gmail.com on 6 Nov 2011 at 12:15

[GoogleCodeExporter]

Yeah - that works for me - the Pre-RunPicasa.bat and Post_RunPicasa.bat.

However, before having read this, in my drive home from a movie tonight, it 
occurred to me the beauty of your new dialog design.  With the new "tabbed" 
pages of the dialog, I envisioned a third tab, "Advanced" - a tab where 
advanced features or options could be applied/configured.
:-)

But again, thanks, the Pre/Post_RunPicasa.bat is nice to have!

Original comment by bkea...@keadle.net on 6 Nov 2011 at 12:29

[GoogleCodeExporter]

Ok, Now I am reaching, but I will ask anyway:
When you call the BAT file, you could pass it some parameters on the command 
line. If you did, what should they be? Picture directory? Mapped drive? 
Settings directory?
???
(Was I the one that was just saying this was getting complicated?)

Original comment by earlb...@gmail.com on 6 Nov 2011 at 5:19

[GoogleCodeExporter]

Always pushing the bounds ;-).

And it's even a non-chargable feature request:

*Client*: I would like extra parameters passed to the batch file
*IT supplier*: Yes, that coulc be possible but might be some work...
*Client*: OK, how many lines of code will it be... I'll pay 5 $/ line of
code
*IT supplier*: Grmbl :-(, no extra lines of code, only pass some extra
parameters to a function :-(...


Hmm... I should get some more sleep I think, how bad can you humor get :-).

Pieter

Original comment by pieter.r...@gmail.com on 6 Nov 2011 at 8:45

[GoogleCodeExporter]

Hmmm...good thought (passing parameters).  I'm not sure what might be consider 
to pass.  That's where a new "Advanced" tab in the PS dialog would come in 
handy.  :-)  But then it's no longer a "hidden feature".

Original comment by bkea...@keadle.net on 6 Nov 2011 at 11:52

[GoogleCodeExporter]

Well, as for the parameter passing, I was actually thinking about Bryan's first 
reason for wanting this feature. I figured it would be handy if he knew where 
the picture directory was if he was going to copy a folder full of pictures 
there :-)

It would be nice if you didn't have to set variables in the cmd file.

another one might be the settings file location.  I know we wouldn't think of 
all the things people might need, but I guess if we defined the first couple so 
they were useful, we could always add on later.

Would the Exit file need different ones? it might be calling an external backup 
solution?

Original comment by earlb...@gmail.com on 6 Nov 2011 at 5:52

[GoogleCodeExporter]

Along with passing parameters (or perhaps instead of) can environment variables 
be set for the .BAT environment?  That would be great then some standard 
variables can be defined as PS sees it, and when it calls the .BAT, it inherits 
those variables, and then could be used within the .bat files as needed!  For 
example, PS would establish relevant variables:
   _PSPICTURES=%UserProfile%\My Pictures
   _PSBACKUPROOT=D:\Backups
   _PSDBNAME=Our Album
   _PSSHAREPATH=\\bkeadle-t3200\Photos
   (etc)

Then when the Pre/Post .bat get's run, you have all the _PS* variables to work 
with!

       set | find "_PS"

Original comment by bkea...@keadle.net on 6 Nov 2011 at 6:08

[GoogleCodeExporter]

I would think it would be instead of....Unless there was something universally 
used that could be passed in the command line, but doing both ups the 
complexity again.

Pieter, I know we screw with the user profile/environment with PS, does any of 
that affect environmental variables?  Also we do it differently with XP than 
Vista+, any worries?

Original comment by earlb...@gmail.com on 6 Nov 2011 at 6:46

[GoogleCodeExporter]

1) Advanced tab: I don't have any principal problems with an advanced tab... 
that way the advanced stuff still doesn't clutter the interface, and as it is 
an "advanced" tab, "non-power" users know this is difficult stuff.
Nonetheless, I don't think it is necessary to put it in the advanced tab... we 
can just pass all the variables, maybe as key-value pairs to be flexible, and 
then it's up to the creator of the batch file to use them or not.
2) environment variables are possible as well... same work, but extra lines of 
code :-). Maybe even cleaner, in the code of the .bat file: this way you have 
decent variable lines immediately instead of the parameter numbers... so I vote 
for environment variables.
3) PicasaStarter overrides the %USERPROFILE% environment variable (and maybe 
some other ones, I don't know it by heart anymore to fool Picasa to put the 
Picasa database somewhere else.... so in the .bat file you need to kniow that, 
otherwise you get weird things... It is a choice though, if we call the bat 
files a few lines earlier, it won't be changed yet... and maybe that's better 
(less confusing)

Original comment by pieter.r...@gmail.com on 7 Nov 2011 at 5:16

[GoogleCodeExporter]

Obviously, we would need to set any variables that are already set...
and I recommend coming up with a common prefix, as I offered "_PS(var)" so that 
one can find all the PicasaStarter environment variables provided, easily with 
the command:
    set | find "_PS"

Original comment by bkea...@keadle.net on 7 Nov 2011 at 5:35

[GoogleCodeExporter]

PS doesn't use many environmental variables at the moment, but could certainly 
use a common prefix for any it uses internally or exports to the environment. 
The trick is figuring out what is useful, and what is practical to send to the 
environment.
For instance the picture directory is not really known by PS, it is in the 
database (in the watched folders file), and there could easily be several 
watched folders, so do we set up variables for each of them, or give the 
database path, or the path to the file as a variable, or? The PS settings 
directory should probably be there, certainly the database directory.  What 
else?

Original comment by earlb...@gmail.com on 7 Nov 2011 at 7:59

[GoogleCodeExporter]

Oh yes,  If we incorporate the runpicasa stuff, then the source and destination 
path(s)

Original comment by earlb...@gmail.com on 7 Nov 2011 at 8:04

[GoogleCodeExporter]

Yeah, potentially any preference defined in RunPicasa/PS would be a candidate 
for an environment variable (I'm so pleased this is an option which will 
provide a lot of flexibility).

The "normal" picture directory would already be set with existing variables 
(%USERPROFILE%\Pictures), but, as you say, watched directories are defined in 
the DB.  Unless we have a way to read that DB, I don't see how can provide 
useful information that isn't otherwise set/defined within PS dialog.

Is it unreasonable to set some guidelines for using PS effectively, and specify 
the conditions where PS can backup your photos?  If you put photos in any other 
directory, they will not be backed up - not actually a bad idea actually to 
know that   photos located in specific folders are backed up, but others 
aren't? That could be a defined feature - do you really want/need a backup of 
print screens, for example?

If we go along that line of thinking, we'd say the following directories will 
be backed up with PS backup:
1) "My Pictures" folder (%UserProfile%\Pictures
2) Network share path defined in PS database profile
3) Any/all local drives containing a "Photos" directory at the root of the 
drive.
#3 providing some flexibility in putting photos elsewhere providing it's a 
"Photos" folder at the root of any drive.  Just an idea.

Otherwise, beyond that, any other directories as backup candidates would have 
to be a dialog provided in PS which, again, would translate to some environment 
variable(s) that could also be utilized within Pre/Post batch file.


Perhaps requiring some 

Original comment by bkea...@keadle.net on 7 Nov 2011 at 10:39

[GoogleCodeExporter]

Changed title so it reflect the practical feature request

Original comment by pieter.r...@gmail.com on 8 Nov 2011 at 8:52

• Changed title: Power users should be able to let a scrept execute before and after Picasa is started from PicasaStarter

[GoogleCodeExporter]

The following environment variables should now be set (not tested)
PS_PicasaDBGoogleDir
PS_SettingsDir

Original comment by pieter.r...@gmail.com on 8 Nov 2011 at 10:28

[GoogleCodeExporter]

Title bar of latest v2 beta5 still says v1.7.0.1 

Original comment by bkea...@keadle.net on 9 Nov 2011 at 12:11

[GoogleCodeExporter]

Just put Pre_Picasa.bat and Post_Picasa.bat in my PicasaStarter directory and 
launched, but didn't see a call to it.  This is the script I'm using to test:


@echo off
TITLE %~DP0 %*
echo.
echo %~DP0 %*
echo.
set | find "PS_"
echo.
pause

Original comment by bkea...@keadle.net on 9 Nov 2011 at 12:17

[GoogleCodeExporter]

Hi Bryan:
The bat file names are:
Pre_RunPicasa.bat
Post_RunPicasa.bat

I haven't tried to see if they work...

No, I didn't see anything either
Earl

Original comment by earlb...@gmail.com on 9 Nov 2011 at 3:46

[GoogleCodeExporter]

Correct...those are the filenames I have.

Original comment by bkea...@keadle.net on 9 Nov 2011 at 3:54

[GoogleCodeExporter]

Hi Pieter:
you forgot the "\\" in this line in the StartBatFile Routine

                string batFilePreRunPicasa = picasaStarterExeFile.DirectoryName + "\\" + fileName;

Earl

Bryan:
I'll put a exe in the dropbox

Original comment by earlb...@gmail.com on 9 Nov 2011 at 4:02

[GoogleCodeExporter]

Hi Bryan:
There is another issue, Picasa starts even though the bat file isn't finished.

I think that's a problem
But here is the file anyway

Original comment by earlb...@gmail.com on 9 Nov 2011 at 4:09

Attachments:

• [Test PicasaStarter.zip](https://storage.googleapis.com/google-code-attachments/picasastarter/issue-28/comment-30/Test PicasaStarter.zip)

[GoogleCodeExporter]

OK, that worked - it found it and ran it, but it did not wait for the .BAT to 
exit before launching Picasa - it should.

Original comment by bkea...@keadle.net on 9 Nov 2011 at 4:13

[GoogleCodeExporter]

Oops, I "refactored" the code slightly yesterday evening (moved it to a 
function ;-)) and apparently I forgot a backslash.

The newest "alpha" waits for the bat file to end.

Original comment by pieter.r...@gmail.com on 9 Nov 2011 at 6:50

[GoogleCodeExporter]

Hi Pieter:
I was thinking about having the bat files in the PS exe folder, which is the 
right place I think, but I think that should be referenced in the code as the 
settings directory. My reason is:
When PS is on a network drive, I am likely to run a local copy of PS which uses 
the network "shared" settings file, and in this case, if there are bat files, I 
would want to be using the bat files associated with the settings file, not any 
local bat files.
In the code you look for the bat files in the PS exe directory which would be 
wrong in this case.

I would just start changing the code, but you are in too much of a creative 
frenzy here and I don't want to get in the way!

Original comment by earlb...@gmail.com on 9 Nov 2011 at 5:41