<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.4" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: 1.1.1 Release</title>
	<link>http://juploadr.org/2006/09/10/111-release/</link>
	<description>a photo uploader for Linux, Mac and Windows</description>
	<pubDate>Sat, 22 Nov 2008 04:42:34 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>by: James D. Ivey</title>
		<link>http://juploadr.org/2006/09/10/111-release/#comment-1818</link>
		<pubDate>Mon, 12 Feb 2007 06:16:25 +0000</pubDate>
		<guid>http://juploadr.org/2006/09/10/111-release/#comment-1818</guid>
					<description>Many thanks!  Was using Gwenview.  Fired up Konqueror and it's accepting drops just fine!

Thanks again!

Jim</description>
		<content:encoded><![CDATA[<p>Many thanks!  Was using Gwenview.  Fired up Konqueror and it&#8217;s accepting drops just fine!</p>
<p>Thanks again!</p>
<p>Jim
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: scohen</title>
		<link>http://juploadr.org/2006/09/10/111-release/#comment-1613</link>
		<pubDate>Wed, 17 Jan 2007 23:42:19 +0000</pubDate>
		<guid>http://juploadr.org/2006/09/10/111-release/#comment-1613</guid>
					<description>Jim,
From what application are you dragging the photos? jUploadr needs a GTK or QT application to  be the initiator of a drag --otherwise, you get no results. It's a limitation of the toolkit that I use, and speaks to the fragmented nature of linux desktops. 

I know for a fact that Nautilus, gThumb and Konqueror are all supported.</description>
		<content:encoded><![CDATA[<p>Jim,<br />
From what application are you dragging the photos? jUploadr needs a GTK or QT application to  be the initiator of a drag &#8211;otherwise, you get no results. It&#8217;s a limitation of the toolkit that I use, and speaks to the fragmented nature of linux desktops. </p>
<p>I know for a fact that Nautilus, gThumb and Konqueror are all supported.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: James D. Ivey</title>
		<link>http://juploadr.org/2006/09/10/111-release/#comment-1603</link>
		<pubDate>Wed, 17 Jan 2007 05:07:27 +0000</pubDate>
		<guid>http://juploadr.org/2006/09/10/111-release/#comment-1603</guid>
					<description>I've just joined Flickr and was excited to find this tool.  I use Linux -- Xandros BizEd 3.  I haven't upgrade to Xandros 4 yet, but probably will soon.

So far, I can't get jUploadr to accept dragged images -- i.e., no can drop.  I've seen elsewhere the question "Is the O/S allowing the drop?" in the answer to similar problems.  The short answer is that I don't know.

Here's my Java version:
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)

I installed jUploadr as root in the usual location (/usr/local/src/jUp...).

I'm running jUploadr as an ordinary user.

Do I need some write access somewhere to allow the dropping?  Xandros is slow to upgrade packages (except when security is at issue).  For example, I'm using Firefox 1.5.  Are there prerequisite packages (other than Java) that I should check for currency?  Should I just install directly for each user and not as root in some central place?  Do I need to set up links somewhere?

Any help is greatly appreciated.

Jim</description>
		<content:encoded><![CDATA[<p>I&#8217;ve just joined Flickr and was excited to find this tool.  I use Linux &#8212; Xandros BizEd 3.  I haven&#8217;t upgrade to Xandros 4 yet, but probably will soon.</p>
<p>So far, I can&#8217;t get jUploadr to accept dragged images &#8212; i.e., no can drop.  I&#8217;ve seen elsewhere the question &#8220;Is the O/S allowing the drop?&#8221; in the answer to similar problems.  The short answer is that I don&#8217;t know.</p>
<p>Here&#8217;s my Java version:<br />
java version &#8220;1.5.0_06&#8243;<br />
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)<br />
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)</p>
<p>I installed jUploadr as root in the usual location (/usr/local/src/jUp&#8230;).</p>
<p>I&#8217;m running jUploadr as an ordinary user.</p>
<p>Do I need some write access somewhere to allow the dropping?  Xandros is slow to upgrade packages (except when security is at issue).  For example, I&#8217;m using Firefox 1.5.  Are there prerequisite packages (other than Java) that I should check for currency?  Should I just install directly for each user and not as root in some central place?  Do I need to set up links somewhere?</p>
<p>Any help is greatly appreciated.</p>
<p>Jim
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: slawekm</title>
		<link>http://juploadr.org/2006/09/10/111-release/#comment-1318</link>
		<pubDate>Mon, 27 Nov 2006 23:14:18 +0000</pubDate>
		<guid>http://juploadr.org/2006/09/10/111-release/#comment-1318</guid>
					<description>Cite after Andi:

- after an authorisation the account name is “null-account@Flickr” (nevertheless upload works well)
- the authorisation gets lost after quiting the program

This is the main problem with release 1.1.1 (also with 1.1). Authorization is not saved permamently. The same method works in version 1.0. Deleting config directory also doesn't help. OS: GNU/Linux (Ubuntu 6.10 Edgy Eft).

Feel free to contact me for further details.</description>
		<content:encoded><![CDATA[<p>Cite after Andi:</p>
<p>- after an authorisation the account name is “null-account@Flickr” (nevertheless upload works well)<br />
- the authorisation gets lost after quiting the program</p>
<p>This is the main problem with release 1.1.1 (also with 1.1). Authorization is not saved permamently. The same method works in version 1.0. Deleting config directory also doesn&#8217;t help. OS: GNU/Linux (Ubuntu 6.10 Edgy Eft).</p>
<p>Feel free to contact me for further details.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Mat</title>
		<link>http://juploadr.org/2006/09/10/111-release/#comment-1311</link>
		<pubDate>Sun, 26 Nov 2006 15:58:50 +0000</pubDate>
		<guid>http://juploadr.org/2006/09/10/111-release/#comment-1311</guid>
					<description>Sorry: just figured when reading the rest of comments that this request got already posted and that you requested to post in the sourceforge-feature-request.
I posted it over there as well...sorry for the double-messaging.

Mat</description>
		<content:encoded><![CDATA[<p>Sorry: just figured when reading the rest of comments that this request got already posted and that you requested to post in the sourceforge-feature-request.<br />
I posted it over there as well&#8230;sorry for the double-messaging.</p>
<p>Mat
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Mat</title>
		<link>http://juploadr.org/2006/09/10/111-release/#comment-1309</link>
		<pubDate>Sun, 26 Nov 2006 15:49:03 +0000</pubDate>
		<guid>http://juploadr.org/2006/09/10/111-release/#comment-1309</guid>
					<description>Hey!

Great App you created here! Looks very smooth and works very seamlessly with flickr! Love it!

Just one thing: Could you please try to handle the IPTC tags a little bit more sofisticated? Similarly to the way the flickr-upload-tool handles them:
I have tons of pictures that I'm just assigning a title but not a description. What I would expect to happen now, is that the Uploading-Tool takes this as the title and leaves the description empty. What the Flickr online-upload-tool does, is adding this IPTC-Title inside the title AND the description, which is better than nothing...but not perfect.
But what your tool does at the moment is adding the FILENAME as title and putting the IPTC-Title as Description, which is really a pity, because the Filename is not what is most important as information to be displayed...

Anyway: Great app. anyway!

Have a nice day!

mat</description>
		<content:encoded><![CDATA[<p>Hey!</p>
<p>Great App you created here! Looks very smooth and works very seamlessly with flickr! Love it!</p>
<p>Just one thing: Could you please try to handle the IPTC tags a little bit more sofisticated? Similarly to the way the flickr-upload-tool handles them:<br />
I have tons of pictures that I&#8217;m just assigning a title but not a description. What I would expect to happen now, is that the Uploading-Tool takes this as the title and leaves the description empty. What the Flickr online-upload-tool does, is adding this IPTC-Title inside the title AND the description, which is better than nothing&#8230;but not perfect.<br />
But what your tool does at the moment is adding the FILENAME as title and putting the IPTC-Title as Description, which is really a pity, because the Filename is not what is most important as information to be displayed&#8230;</p>
<p>Anyway: Great app. anyway!</p>
<p>Have a nice day!</p>
<p>mat
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: scohen</title>
		<link>http://juploadr.org/2006/09/10/111-release/#comment-1286</link>
		<pubDate>Fri, 03 Nov 2006 04:07:58 +0000</pubDate>
		<guid>http://juploadr.org/2006/09/10/111-release/#comment-1286</guid>
					<description>Steve,
Oh, it leaks a little bit of memory if you add a ton of photos at once. I'm preparing a 1.1.2 release to fix that though.

You should not have to re-auth every time you start the app. It might behoove you to erase the file ~/Library/Preferences/org.scohen.juploadr.plist and start from scratch.</description>
		<content:encoded><![CDATA[<p>Steve,<br />
Oh, it leaks a little bit of memory if you add a ton of photos at once. I&#8217;m preparing a 1.1.2 release to fix that though.</p>
<p>You should not have to re-auth every time you start the app. It might behoove you to erase the file ~/Library/Preferences/org.scohen.juploadr.plist and start from scratch.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: steve</title>
		<link>http://juploadr.org/2006/09/10/111-release/#comment-1283</link>
		<pubDate>Wed, 01 Nov 2006 01:35:28 +0000</pubDate>
		<guid>http://juploadr.org/2006/09/10/111-release/#comment-1283</guid>
					<description>Hi, I'm running on Mac OS 10.4.8.

I like everything, especially that it doesn't have a memory leak like the official Flickr mac uploader.  But I have the same problem as Andi.  Each time I start the program I have to re-authenticate and reset my preferences.  It would be nice for this to be saved.</description>
		<content:encoded><![CDATA[<p>Hi, I&#8217;m running on Mac OS 10.4.8.</p>
<p>I like everything, especially that it doesn&#8217;t have a memory leak like the official Flickr mac uploader.  But I have the same problem as Andi.  Each time I start the program I have to re-authenticate and reset my preferences.  It would be nice for this to be saved.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Irae</title>
		<link>http://juploadr.org/2006/09/10/111-release/#comment-1282</link>
		<pubDate>Tue, 31 Oct 2006 00:06:19 +0000</pubDate>
		<guid>http://juploadr.org/2006/09/10/111-release/#comment-1282</guid>
					<description>Yep, I've tryed this before.

I got the error messagens, but when I close those the program simply closes...  not even the "reopen" button with the message that normaly is presented when some program closes itself unexpectedly...

The only way is not to drag a movie file to it...

I was thinking. Is there a way to validate the files before generating the thumbnails? I was about to upload 250 photos of about 2Mb each to my pro account. The thumbs take much time to generate. Or may be if ou use the embeded thumbnail generated by the camera itself? Don't know... but IMHO its better to sort out the problem before de lengthy tasks.

Many thanks for the fast responses and contact-me if you think I can help you sorting out the problem.</description>
		<content:encoded><![CDATA[<p>Yep, I&#8217;ve tryed this before.</p>
<p>I got the error messagens, but when I close those the program simply closes&#8230;  not even the &#8220;reopen&#8221; button with the message that normaly is presented when some program closes itself unexpectedly&#8230;</p>
<p>The only way is not to drag a movie file to it&#8230;</p>
<p>I was thinking. Is there a way to validate the files before generating the thumbnails? I was about to upload 250 photos of about 2Mb each to my pro account. The thumbs take much time to generate. Or may be if ou use the embeded thumbnail generated by the camera itself? Don&#8217;t know&#8230; but IMHO its better to sort out the problem before de lengthy tasks.</p>
<p>Many thanks for the fast responses and contact-me if you think I can help you sorting out the problem.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: TravisP</title>
		<link>http://juploadr.org/2006/09/10/111-release/#comment-1281</link>
		<pubDate>Mon, 30 Oct 2006 15:32:44 +0000</pubDate>
		<guid>http://juploadr.org/2006/09/10/111-release/#comment-1281</guid>
					<description>Steve,

I love this program, it saves so much time uploading to zooomr. The only nit-picky thing I have is with the tags. The problem is this.

Say I have 10 pics on the juploadr window. I select them all and add a tag to them, maybe 'travel'. I then select four of those pics and add in the tag 'country'. I then deselect those pics and select four pics, but include two of the pics I had previously added 'country' to and add in another tag, say 'mountains'. What happens is that in grabbing photos that already had tags on them and adding new tags, it actually adds some of the common tags in twice.

I hope that makes sense.

Can I suggest that in the tag window, if there are common tags, it greys them out or something and doesn't add them again. Of course you would still be able to change them, but it would apply it to all of the selection, therefore changing the greyed tag would change it for all of the selected photos, but not add it in again.</description>
		<content:encoded><![CDATA[<p>Steve,</p>
<p>I love this program, it saves so much time uploading to zooomr. The only nit-picky thing I have is with the tags. The problem is this.</p>
<p>Say I have 10 pics on the juploadr window. I select them all and add a tag to them, maybe &#8216;travel&#8217;. I then select four of those pics and add in the tag &#8216;country&#8217;. I then deselect those pics and select four pics, but include two of the pics I had previously added &#8216;country&#8217; to and add in another tag, say &#8216;mountains&#8217;. What happens is that in grabbing photos that already had tags on them and adding new tags, it actually adds some of the common tags in twice.</p>
<p>I hope that makes sense.</p>
<p>Can I suggest that in the tag window, if there are common tags, it greys them out or something and doesn&#8217;t add them again. Of course you would still be able to change them, but it would apply it to all of the selection, therefore changing the greyed tag would change it for all of the selected photos, but not add it in again.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
