GTK+ Forums

I'm still working on a typing-to-speech program for the speech impaired or those who cannot speak but can type.
I need help figuring out how, when displaying an already-written text file to move around: perhaps to the previous file of text to the next file.

I use gvim for the user to type into. The text is stored in files like: ~/.VBC/talk.7.txt;
It's from a file like this that the text is fopen()'d. From this function:

void show_file_in_new_window (void)
{
}

Opened by pressing the "Display Text" button, a separate window is displayed in case someone wants to listen to something the user has said before.
At the bottom of "show_file_in_new_window()" are four buttons:

"Play" "Next" "Last" "Close Window"

I would like help from the forum in helping me automatically open the "Next" and "Last" windows.
Anybody?

gary kline

PS: FYI: the program in around 1100 lines *with* debug statement.

Ok the gnome desktop already has some pretty good features in terms of accessibility. Maybe not so much GNOME3 which is still catching up accessibility wise but it'll get there hopefully.
There's a whole wealth of tools available so you don't have to go reinventing the wheel.

GTK has a inter-process drag and drop interface which I'd advise strongly in favour of using. As you talk about stuff the user has said before it would be ideal if information could be taken from any number of programs/files the user has typed in before and be able to pull them over into your window. The flip-side of this is that the user may already have a number of windows already open and it may be best not to force new windows opening. The look I'd imagine is one single large text entry with your play etc. buttons underneath and an index of sources to the right. Left clicking on an item in the list would bring up that items associated text and with right clicking on it then you could offer opening in a new window or a new tab.

Yes, there may be several gvim windows open--this if the person who cannot speak leaves his gvim instantiations open. I would recommend doing a ":wq" after each gvim during the conversation.

What you seem to be thinking of is WAY beyond my abilities in the gtk-pworld. [I last hacked on this project last February; I only picked it up a few days ago.]

My philosophy is to keep the C+gtk program as simple as possible. Since the user can have the computer speak for them and then close the window, few windows would need to be open.
If the user {and whoever they were talking to} could "Next"/"Last" through as many files of text as there were, so much the better.

I just need to figure out how to have the function "show_file_in_new_window()" open the next or last "talk.N.txt" file.
As it is I have an "int counter = 1;" as a global index. Since this program is intended for a dialog, the value of N won't go that high.

Store all the filenames in a doubly linked list (GLib's GList http://developer.gnome.org/glib/stable/glib-Doubly-Linked-Lists.html) and then use list->next, list->prev to get next previous filenames and g_list_first and g_list_last to get the first and last files. glib has some file handling functions as well that will be of use.

Yes, this would make sense if the original files did not already exist as physically arrays of text:

talk.1.txt,
talk.2.txt,
.
.
talk.17.txt,

Lets say. The easiest way I could do the Next/Last print-toscreen-window-and-PLAY would be to check if the textfiles existed:
// pseudo-code:
if buffer[12] != NULL
then call "show_nextORlast_file_in_new_window()"

and duplicate the entire 120 lines of gtk code that would dshow the buffer or else print:
fprintf(stderr, "No such textfile!):

This was what I was thinking of last February when I took a break.

Thanks much for your linked list suggestion. If the gnome-accessibility folks think my code is worth including ---in light f the netbooks and tablet devices and whatever new technology is in vogue, they/somebody might rewrite much of my code.

Sorry it was a fairly open ended question you posed and I didn't know what constraints you were working under so assumed you had full freedom of design. Are you able to provide any more information on what already exists or a link to a repository from which you are developing?

There should be no need to duplicate code as whether you are selecting next, last etc. The window you pull up should be more or less the same as the original (excepting that there's probably not much point having a next/last button when you're at the end of the list). For each signal connect you do to a button, you can pass one data pointer to the callback. If you don't have freedom to pick your data structure then in this case I'd pass the index around; i++ for next and the length of the array for last (unless you can cleverly arrange it in reverse order so that the last is index 0 - making next i--). In order to pass an integer as a pointer in the callback you'd have to cast it with GINT_TO_POINTER and GPOINTER_TO_INT.

Any suggestions on where I can set up a repository?
One reason I switched my server from FBSD to linux was that FBSD was massively hard to upgrade.
I am looking forward to setting up some forum software but that will be awhile.

You are right that I don't really need any next_last function to display my "new_window".
I think you were among the people who helped me write that function. It is quite a ways over my head since I'm too new to GTK.

The function deals with a "frame":

frame = gtk_frame_new ("Speak text");
gtk_container_add (GTK_CONTAINER (window), frame);

and when I close this window, it also closes the main program!

Here is where the close button is created?, and below, where the window is closed.
As I said above, it blows away the "new_window" and the whole program itself, yipes!
How can I close just the new_window of text?

closebtn = gtk_button_new_with_label ("Close window");
.
.
gtk_box_pack_end (GTK_BOX (hbox), closebtn, TRUE, TRUE, FALSE);

How you create and pack the button isn't going to effect its behaviour on closing. This is going to be determined by the function you call in connecting a signal to it. If its gtk_main_quit then yes the whole program will go down. If its just gtk_widget_destroy(window) then this should just shut down the particular window. You will likely need to have a custom close function you call in order to free up memory associated with that particular window and then check if you have any windows left and if not then call gtk_main_quit (I don't know if you have a centralised window different from all these others).

Regards web-hosting, have a look at http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities. Which one is best for you will depend on if you know any version control software, if you are targeting a certain distribution and what community support you might garner. When I started out I only knew of sourceforge and google code, but discovering they were pawns of US foreign policy quickly put me off them (e.g. http://code.google.com/projecthosting/terms.html). If you don't know any version control and want to learn one, the gtk code is hosted in git repositories (http://git.gnome.org/browse/gtk+/tree/) so learning git would be useful (though it is a bit of a steep learning curve) as the ATK people would be used to working with it and be able to import it well. In such a case I'd probably go with github as its quite good at helping people learn git along the way and has a big following making getting answers to questions easier.

The Gnome University Project (GU) in the announcements section, as well as many other projects are on GitHub.

Git does have a bit of a steep learning curve but I highly recommend Michael Marner's GitHub tutorials on Youtube.
He does a great job in his video's with both the concepts and hands on, he's funny and interesting to listen to and has this great Australian accent.
http://www.youtube.com/watch?v=HaSDIdNkCDQ&playnext=1&list=PL782E6284B60DD0B2&feature=results_main

There's also the "official" video's on GitHub.
http://learn.github.com/p/intro.html

I think this new_window() is unrelated to anything in main(). As prev'ly noted, I took months off from working on this project. I have found where this window gets closed. it is beyond my ken, tho. If a simple gtk_widget_destroy() would do the trick, it would solve a lot of problems.

The code to close the window that displays and plays back what was already spoken is this:

/* since this button is to remove the window, i pass
* the window as the data and then pass the window
* to gtk_widget_destroy() inside the cb
*/
gtk_signal_connect (GTK_OBJECT (closebtn), "button_press_event",
(GtkSignalFunc) remove_text_window, window);

It is probably evident that I was flying blind when i wrote this.


I've talked to enough people who are interested in this project that if i give them a site, it ought to become known. Besides, there really isn't that much left to do. I've been using RCS since it showed up, and CVS at work. I know zip about git, but it's time to learn. {And I will check out your URL's... . Thankee.)