Re: discoveries! gtk DOES dim... how can i infinite-loop?

[Michael Torrie]

On 01/21/2012 09:49 PM, Gary Kline wrote:
>   this sound very much worth looking into and i will ... just
>   as soon as i figure out what is causing my gtk app to dim.

I did give you the key to keeping GTK from dimming in my other post.
It's pretty easy to iterate the main loop while you are looping in your
own while loop.

Anyway my code is complete and, except for saving the text and
abbreviations to disk, it does everything you want with no need to try
to drive gvim or anything.  You could add the save to disk stuff quite
quickly (even having to learn python!)  And of course my secret wish is
for you to learn python as you really will be able to code up these
sorts of things 2-3 times faster than C.  It's really quite something.
My error rate per lines of code drops by a factor of 2 more compared to C.

I would like some feedback on its operation.  I want to know if the
mechanism for doing abbreviations is as usable as your gvim method.  The
tarball I posted is already out of date.  use the git repository url I
posted instead.  (git clone
http://www.torriefamily.org/~torriem/tts_assist.git).

cheers,
Michael
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: discoveries! gtk DOES dim... how can i infinite-loop?

[Gary Kline]

On Fri, Jan 20, 2012 at 09:20:40PM +0900, Tristan Van Berkom wrote:
> Date: Fri, 20 Jan 2012 21:20:40 +0900
> From: Tristan Van Berkom 
> Subject: Re: discoveries! gtk DOES dim... how can i infinite-loop?
> To: Gary Kline 
> Cc: David Ne??as , GTK Devel List
>  
> 
> On Fri, Jan 20, 2012 at 8:12 AM, Gary Kline  wrote:
> > On Thu, Jan 19, 2012 at 11:18:22AM +0100, David Ne??as wrote:
> >> Date: Thu, 19 Jan 2012 11:18:22 +0100
> >> From: David Ne??as 
> >> Subject: Re: discoveries! gtk DOES dim... how can i infinite-loop?
> >> To: Gary Kline 
> >> Cc: GTK Devel List 
> >>
> >> On Thu, Jan 19, 2012 at 12:58:09AM -0800, Gary Kline wrote:
> >> > i've spent the last many days tryoing [on ubuntu] anf tonight on my
> >> > EEE-900A netbook [debian].  both dim when i go into a recursive
> >> > loop.
> >> >
> >> > 1.  edit with gvim
> >> > 2.  have espeak voice gvim when it is written
> >> > 3 goto 1;
> >> >
> >> > tonight i did everything absolutedly write in chercking various
> >> > things, but the app still dimd if i have the function call itselg.
> >> >
> >> > i should have asked this list whether there there is  a gtk call
> >> > that let's things go into  either  an infinite loop, or, would a
> >> > for() loop work for 300-500 loops?
> >> >
> >> > if not, i need to rethink my algorithm.
> >>
> >> That is probably what you have to do.
> >>
> >> If I understand what your code does (and how) then while gvim is running
> >> your app is *not*.  Your app is blocked and waits until gvim terminates.
> >> The same for espeak.
> >
> >
> >        i think you have it nailed!  [g]vim creates a .SWAP file in
> >        the pwd; so since gvim creates .talk.N.txt.swp while the
> >        textfile is being types into, i do a while(!done) check on
> >        the .swap file.  then i do a second while loop while
> >        talk.N.txt exists.  finally, espeak [flags] | aplay speaks
> >        the words in the text file.  [ i tee the output of espeak
> >        and hand it off to aplay because of strange driver bugs here
> >        on my desktop.]
> >
> >
> >>
> >> You need to use a function such as g_spawn_async() to execute it.  Then
> >> it depends how you communicate with the programs.  If you just want to
> >> know when it terminates use waitpid().
> >>
> >
> >        thanks much.  i'll check g_spawn_async() to see how it is
> >        used.  i hadn't thought of any of the flavors of wait;
> >        everything has worked: gvim//write-quit/espeak a dozen
> >        times.
> >        but the gtk app is greyed and the quit button doesn't work!
> 
> FWIW, we have g_child_watch_add() which is generally easier to
> use than calling waitpid() directly (usually you don't want to
> block on waitpid(), so you would have to handle the SIGCHLD unix
> signal and then call waitpid() from the unix signal, which has
> effectively pre-empted your process... since doing all of this
> is much more complex than it needs to be, I highly recommend
> using g_child_watch_add() to do this safely for you).
> 
> Cheers,
>  -Tristan
> 
i just check my ancient code in ~/devel/muuz {where i was
hacking away on my "mind-machine."  it's been 2001 since i
last touched the wait() stuff.  cannot Believe how much
trouble i had with that   [[i dont swore an oath to Zeus
that i wouldn't get that deep into signal handling.  if i
had`xxdbg.  hm.  ...you never know when the next tree branch
is going to knock out the power!!]]


gary
 
> 

-- 
 Gary Kline  kl...@thought.org  http://www.thought.org  Public Service Unix
   Journey Toward the Dawn, E-Book: http://www.thought.org
  The 8.57a release of Jottings: http://jottings.thought.org
 Twenty-five years of service to the Unix community.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: discoveries! gtk DOES dim... how can i infinite-loop?

[Gary Kline]

On Thu, Jan 19, 2012 at 09:05:47PM -0700, Michael Torrie wrote:
> Date: Thu, 19 Jan 2012 21:05:47 -0700
> From: Michael Torrie 
> Subject: Re: discoveries! gtk DOES dim... how can i infinite-loop?
> To: Gary Kline 
> CC: GTK Devel List 
> 
> Gary, based on conversations in the past about what you are trying to
> do, I whipped up a little program that just might approach what you are
> trying to do.  If I understand you correctly, you wish to do the following:
> 
> - type text in an editor where abbreviations are expanded (by macros in
> gvim or some other mechanism in another editor) to full words or
> phrases, so that you can compose text faster, even with disabilities.
> - speak the written text with espeak the text
> - save what was spoken so you can load it back up and re-speak it, or
> edit it and speak it again.
> 
> Seems like the big requirement is the ability to use abbreviations.  I'm
> not clear on how gvim does it for you, but the GtkSourceView2 widget
> (not part of GTK, but all distros have it and it's fully integrated with
> GTK) supports what are called "Completions."  They are intended for use
> with programming, but they also can function as an abbreviation
> mechanism.  As you type, when an abbreviation is detected it can pop up
> a suggestion that pressing enter will accept, or keep typing and the
> suggestion will change or go away.  Multiple suggestions can be made as
> well.
> 
> So, here's my program.  It's written in Python, since python is one of
> the absolute best languages for rapid prototyping.  This app did not
> take much time to write, and it gave me a chance to refresh my skills
> and learn how to use some more advanced GTK widgets like the TreeView.
> Anyway, my program does not save what was spoken to disk, though that
> can be added very easily.  It does save what was spoken during one
> session of running the program.  As well, currently abbreviations are
> hard-coded in completion.py, but again that could be saved to disk
> easily.  There's already a dialog for editing the abbreviations within
> the program.
> 
> I believe it does most of what you require, and could be expanded very
> rapidly.  It is written in Python, but now that the prototype is made,
> it could be converted to C easily, though there is no advantage in doing
> that really.  The GUI itself was made in Glade-3, so the actual widgets
> and the magic behind the TreeView is hidden somewhat.  Glade has the
> advantage of making it very easy to rapidly develop the GUI.
> 
> Anyway, the source code is here:
> git repo: http://www.torriefamily.org/~torriem/tts_assist.git
> tarball:  http://www.torriefamily.org/~torriem/tts_assist.tar.gz
> 
> You will need to install pygtk2 and gtksourceview2.  On Fedora those are
> the exact package names.
> 
> I think it would be fun to develop this further (perhaps porting to
> GTK3), but I thought I'd post what I had.  If it's not useful, that's
> fine.  Python makes coding fun and very fast!
> 
> Michael
> 


this sound very much worth looking into and i will ... just
as soon as i figure out what is causing my gtk app to dim.

   {by the way, two+ days without power up here in metro
   seattle in what cause the delay in responding.  i was
   getting ready to google up the async call the first time
   the power went South... .}

i am still resty with gtk and thursday night it occurred to
me that sinced i was beginning with the "Run" button, that
*that* might be where i should jump into a loop.  rather
than from my voice_edit recursive function.

gary



-- 
 Gary Kline  kl...@thought.org  http://www.thought.org  Public Service Unix
   Journey Toward the Dawn, E-Book: http://www.thought.org
  The 8.57a release of Jottings: http://jottings.thought.org
 Twenty-five years of service to the Unix community.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk FilechooserWidget

[Axel FILMORE]

There's a gtk_file_chooser_get_filenames () function and a 
gtk_file_chooser_get_files () function

http://developer.gnome.org/gtk3/stable/GtkFileChooser.html#gtk-file-chooser-get-filenames
http://developer.gnome.org/gtk3/stable/GtkFileChooser.html#gtk-file-chooser-get-files

Is it what you are looking for ?

Or maybe you need to handle the selection-changed signal :
http://developer.gnome.org/gtk3/stable/GtkFileChooser.html#GtkFileChooser-selection-changed

Hope this helps.

Regards.

On 21/01/2012 19:33, John Emmas wrote:

On 16 Jan 2012, at 15:07, John Emmas wrote:


I'm working with a Gtk::FileChooserWidget (where the user can select multiple 
files).  Even though multiple selections are possible, as the user selects each 
file I want to display some information about it in a separate box.

But how can I found out which file just got selected?  According to the 
documentation, 'get_filename()' returns a selection at random if there's more 
than one file selected.  So how can I find out which file the user last clicked?


I posted the above a few days ago and I'm guessing that no replies means there 
isn't a way to do this.  If that's the case, can I suggest a change to the 
FileChooserWidget behaviour for a future version of gtk?  Whenever the widget 
contains multiple selections I'd like to suggest that get_filename() should 
return the last item clicked, instead of returning a random item according to 
the current spec.  I can't see much advantage in returning a random item 
whereas returning the last clicked item would be useful IMHO.  For consistency 
it would probably also need to return the last clicked item, even if the last 
operation was to deselect that item.  Don't know how other gtk users feel about 
this...  anyone else feel that this would be better than the current behaviour?

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list




--
Axel FILMORE

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk FilechooserWidget

[John Emmas]

On 16 Jan 2012, at 15:07, John Emmas wrote:

> I'm working with a Gtk::FileChooserWidget (where the user can select multiple 
> files).  Even though multiple selections are possible, as the user selects 
> each file I want to display some information about it in a separate box.
> 
> But how can I found out which file just got selected?  According to the 
> documentation, 'get_filename()' returns a selection at random if there's more 
> than one file selected.  So how can I find out which file the user last 
> clicked?
> 

I posted the above a few days ago and I'm guessing that no replies means there 
isn't a way to do this.  If that's the case, can I suggest a change to the 
FileChooserWidget behaviour for a future version of gtk?  Whenever the widget 
contains multiple selections I'd like to suggest that get_filename() should 
return the last item clicked, instead of returning a random item according to 
the current spec.  I can't see much advantage in returning a random item 
whereas returning the last clicked item would be useful IMHO.  For consistency 
it would probably also need to return the last clicked item, even if the last 
operation was to deselect that item.  Don't know how other gtk users feel about 
this...  anyone else feel that this would be better than the current behaviour?

John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list