Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'url:pypi': 0.03; 'preferred.': 0.04; 'context': 0.05; 'discard': 0.05; 'filename': 0.07; 'filenames': 0.07; 'finished,': 0.07; 'responding': 0.07; '(same': 0.09; 'cc:addr:googlegroups.com': 0.09; 'corresponds': 0.09; 'here?': 0.09; 'least)': 0.09; 'newest': 0.09; 'cc:addr :python-list': 0.10; 'gui': 0.11; 'thread': 0.11; 'assume': 0.11; 'stack': 0.15; '(just': 0.16; '(when': 0.16; 'cc:name:python list': 0.16; 'class)': 0.16; 'command)': 0.16; 'least.': 0.16; 'linux)': 0.16; 'subject:GUI': 0.16; 'subject:image': 0.16; 'wrote:': 0.17; 'directory.': 0.17; 'creates': 0.18; '(or': 0.18; 'windows': 0.19; 'load': 0.19; 'define': 0.20; 'file.': 0.20; 'java': 0.21; 'displayed': 0.22; 'ones.': 0.22; 'mention': 0.23; "haven't": 0.23; 'cc:no real name:2**0': 0.24; 'cc:2**1': 0.24; 'command': 0.24; 'cc:addr:python.org': 0.25; 'header:In-Reply- To:1': 0.25; 'older': 0.27; '(as': 0.27; 'newer': 0.27; 'replace': 0.27; 'message-id:@mail.gmail.com': 0.27; 'far.': 0.29; 'included': 0.29; 'class': 0.29; 'checks': 0.30; '(and': 0.32; 'asking': 0.32; 'url:python': 0.32; 'file': 0.32; 'spread': 0.32; 'real-time': 0.33; 'zero': 0.33; 'monitor': 0.33; 'another': 0.33; 'received:google.com': 0.34; 'mapping': 0.35; 'something': 0.35; 'there': 0.35; 'really': 0.36; 'created': 0.36; 'but': 0.36; 'url:org': 0.36; 'should': 0.36; 'why': 0.37; 'subject:: ': 0.38; 'mean': 0.38; 'object': 0.38; 'possible.': 0.38; 'delete': 0.38; 'think': 0.40; 'most': 0.61; 'latest': 0.61; 'close': 0.63; 'skip:n 10': 0.63; 'more': 0.63; 'replying': 0.64; 'here': 0.65; 'notified': 0.65; 'music': 0.79; '2013': 0.84; 'much,': 0.84; 'oscar': 0.84; 'analyzed': 0.91 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=gb+b4PEETLZrVrcRyZgLwga86iGnoVplYxuBMhnjhOY=; b=uaNl5cWAp6a44FKIRAvpQrdY+B3BLYg99SgeeNjvwnG89wWzgimIzAq1m2ZSMDlW55 nFaFzp3XAS8yGFFtb2I5nvjIOZS7vsa42nDC6FxAT84kuzYLBETbIWyzmgvoAcWJqTlt FmAMg0XZJL837E4lOym0hstRjgbNhaNLSURhp0aCzaAeYfsWtJlEMc3c//S3mKL6HJRy dglFUzm1TFrh0ujjF57ClVQd/aT+KRw9uxCpHkaFdA9izvJnw5hE3cawm10udAw5TgYX AUd680vrzsFqvkqEOf9sS1fVTCB/PjR26K/lcJZiwFT4Yuxos+EqOQUQwuHs/nSo2LjC TbTA== X-Received: by 10.152.131.137 with SMTP id om9mr3246160lab.18.1360288884125; Thu, 07 Feb 2013 18:01:24 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <02bee1ed-1a9b-4cac-975a-098b3382250f@googlegroups.com> References: <8a572770-9cc1-4b65-9053-10fd6c2f543b@googlegroups.com> <02bee1ed-1a9b-4cac-975a-098b3382250f@googlegroups.com> From: Oscar Benjamin Date: Fri, 8 Feb 2013 02:01:04 +0000 Subject: Re: Monitoring updating directory for image for GUI To: ciscorucinski@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Python List , comp.lang.python@googlegroups.com X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 54 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1360288892 news.xs4all.nl 6862 [2001:888:2000:d::a6]:48143 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:38393 On 8 February 2013 00:48, wrote: > Real-time...as close to real-time as possible. That is why I did not real= ly want to use a queue. That is because if a bunch of the thread that creat= e the images finish really close to one another (when they should be spread= out based on how the music is played), then there would be a larger "lag" = in the display. So displaying only the most recent image is preferred. Who/what are you responding to here? You haven't included any context from what you're replying to. > That is why I though Stack...but then that might mean that older images w= ill replace newer ones. > > The Workflow is as such: > > 1) Music is analyzed and streamed to the program. Note-by-Note. > 2) The note is grabbed (same way as a Java Scanner class) > 3) A new thread is created to call an OS command (Lilypond command) > a) Thread waits until command is finished, and Lilypond creates an ima= ge that I can define the filename for in a directory. > > From here I want only the latest one (as close to the latest one at least= ) to be displayed to the gtkImage object in the GUI So you have a thread that updates the image and then checks the stack to see if a new image is available? Can you not just have it only try to load the newest image? You say that you control the filenames of the images. I assume that you are notified when a file is created and given the filename of the new file. So you can maintain a mapping of filename->ordering. In this case you can determine when a file notification arrives whether the filename corresponds to a more recent note than the filename that is currently waiting to be displayed (or is currently displayed). If it is an older note then discard it (and delete the file?) when the notification arrives. If it is newer then discard the one that is currently waiting to be displayed. This way there are always either zero or one filenames waiting and if there is one then it is the most recent one seen so far. > I set up a class that would act as a directory monitor (just stubbed)...t= hat would do all the work I am asking for here Is that using something like watchdog? http://pypi.python.org/pypi/watchdog > > Also, don't think this matters much, but I am using Windows (I seen someo= ne mention Linux) It matters for how you monitor the directory at least. Oscar