Iconify an external program launched with g_spawn_async_with_pipes
Hello, from a gtk+ application I execute an external program in Windows 7 (64 bit) with administrator privileges, and I use a callback function when it exits to elaborate the result. So far, it works. The problem is that I would like to hide or, at least, to minimize (iconify) the external program to not bore the user. I guess that I have to manage the GPid value returned by g_spawn_async_with_pipes, but how? I didn't find any suitable function in gtk. Knowing that GPid is an handle in windows, I used the winapi functions CloseWindow, ShowWindow, MoveWindow, SetWindowPos. They are simply and silently ignored during the execution. Just to check the returned pid, I used TerminateProcess( (HWND)pid , 0) and the external application correctly terminated: i.e. pid is correct. On the other side DestroyWindow is ignored. Do you have any suggestion? Below you can find a simplified version of my code. #include windows.h #include gtk/gtk.h // ... snip ... // gchar *argv[3]; GPid pid; argv[0]= external_program.exe; argv[1]= external_parameter_file.ini; argv[2]= NULL;// g_spawn_async_with_pipes ( NULL, //gchar *working_directory, argv, //gchar **argv, NULL, //gchar **envp, G_SPAWN_DO_NOT_REAP_CHILD | G_SPAWN_SEARCH_PATH, //GSpawnFlags flags, NULL, //GSpawnChildSetupFunc child_setup, NULL, //gpointer user_data, pid, //GPid *child_pid, NULL, //gint *standard_input, NULL, //gint *standard_output, NULL, //gint *standard_error, error); //GError **error); /* Add watch function to elaborate the result of external_program.exe. It will clean any remnants of process. */ g_child_watch_add( pid, (GChildWatchFunc)child_watch_cb, data ); CloseWindow((HWND)pid); // ignored during execution!!! // I tried also the following variants that are ignored: // ShowWindow((HWND)pid, SW_FORCEMINIMIZE); // Tested also other options: SW_HIDE, SW_MINIMIZE, SW_SHOWMINIMIZED, SW_SHOWMINNOACTIVE // MoveWindow((HWND)pid, 10, 10, 10, 10, TRUE); // SetWindowPos( (HWND)pid, 0, 0, 0, 0, 0, SWP_HIDEWINDOW | SWP_NOMOVE | SWP_NOZORDER | SWP_NOSIZE ); // This works and terminates the external application, but this is not obviously my goal // TerminateProcess( (HWND)pid , 0); // ... snip ... // /Giovanni ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk-app to search google scholar
Dear friends, I am trying to make a gtk application that will create a bibtex. The problem is I am a novice in C/gtk programming(this will be only my 2nd programme in gtk). To do that, First and foremost, I need to search google scholar from the code. I tried using lynx and failed. Can anyone kindly show me a simple code in C that can fetch data from google scholar with Import into bibtex entry on? Best and Regards, -- Rudra Banerjee If possible, plz. don't send me MsWord/PowerPoint mails. Why? See http://www.gnu.org/philosophy/no-word-attachments.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gdk threads ...
On 05/22/2012 01:56 AM, Benjamin Otte wrote: Michael Meeksmichael.meeksat suse.com writes: The unfortunate thing about this design is that every toolkit user gets to re-write a bus-load of boiler plate stubs skels and link them into every application. Why not do that, just in a better way, inside the toolkit ? (Disclaimer: This is my personal opinion and is in no way related to the opinion or future API design of GTK or GNOME - though I try to influence both.) I've spent a bit of time thinking about the general why doesn't the framework give us the means to do X? questions as well as the actual use case of libreoffice. And I think the answer to your question is the code should be where the problem is and as your threading model is the problem, the code should be with you. You should be the one motivated to improve things and reduce code, not GTK. I believe this is quite illogical. In short, LibreOffice is just one project being highlighted here (and rather a big one at that). I suspect there are many others that won't be writing to this list or know about such changes until it's too late. I've always believed libraries should do the job that *many* projects would have to re-implement. It just doesn't make sense from a maintenance and bug fixing point of view to have many solutions to the same problem scattered around projects when the common denominator (the toolkit) could do it right for everyone. This just causes work for everyone. Libs in the general GNOME vicinity have historically taken the let's export all the features we have approach. You can set everything everywhere. And if you I actually believed we had the opposite approach in most cases, certainly in terms of the UIs for our applications. can't, there sure is a signal that you can hook into, capture things and do it your way. On the opposite side, libraries like Cairo have taken a different approach: A minimal API and very few ways to hook into the system and influence what is actually happening. I think we should move GNOME closer to the Cairo approach. Reduce the amount of API. You can read http://ometer.com/free-software-ui.html for why that's a good idea. Just replace UI with API and user with developer in that article. I will concede there is usually a sweet spot between *libraries* becoming redundant because they suit all (and suffer performance or other degradation) vs providing enough support for projects using your library. Tracker is a great example of this. The 0.6 versions had APIs which were not powerful enough, so we came up with libtracker-sparql. But, as a result, we now have libraries/frameworks like folks and grilo to provide simpler APIs to get your data. In the end, you could extrapolate from above that we should have a separate library to deal with LibreOffice's situation, but if you can't actually do that without a patched GTK+, it leaves no choice. Now what does that mean for applications that use these APIs that are going to be removed? They're doing the same thing the users do when their preferences get removed: They either change the way they do things, they stick to the old version for as long as possible or they switch to something else. And in the end I'm pretty sure everyone in GNOME-land will be happy to help LO become a great GNOME application. LO is one case. I have written applications which have had to deal with custom even loops working with the GTK+/GLib event loop for their own in-house uses (IPCs, etc). There are just many cases you don't know about. I advocate async, thread free approaches and think it's a mistake to use threads with any UI, but I think it's a bigger mistake to close the door on projects that have no choice. -- Regards, Martyn Founder and CEO of Lanedo GmbH. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk threads ...
On 05/21/2012 04:18 PM, Paul Davis wrote: On Mon, May 21, 2012 at 9:39 AM, Michael Meeks michael.me...@suse.com wrote: That claim sounds really strange; since - well - we do that in LibreOffice ourselves :-) Windows does not allow you to process events/messages for a given window in anything other than the thread that created the window. If you try to do this, you will either crash or cause memory corruption. Michael, it may just happen that the GTK calls you've seen being performed from arbitrary threads in LibreOffice don't result in Win32 event processing and/or window creation, and just update GTK state internally or result in simple Win32 messages being posted. But yes, on Win32 stuff breaks (pretty much immediately) when you call the win32 APIs CreateWindow (or friends) and GetMessage (or friends, the loop APIs) on the same window from another thread than the one that created it. [1] Even if you get the locking right -- even if absolutely only one thread is executing at once in your process -- like Paul said, you still get behavior that at a minimum freezes your window, and in other cases can act a lot like memory corruption. Each Win32 window is 'owned' by a thread, the one that created it, and must have its message loop run on that same thread. That's been a mantra of Win32 development for as long as I can remember. Especially during the COM days. Many of the wild threading models that COM had were a result of this Win32 limitation. I have direct experience with this. When porting a GTK+ application to Windows, I had to move from cooperative threading (ie: big lock) to Win32 fibers (sorta like getcontext/setcontext) to get around this problem. In either case I was only running one stack at once. But running the stacks in different threads broke stuff on Win32. They had to run in the same kernel thread. Cheers, Stef [1] http://support.microsoft.com/kb/90975 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk threads ...
On 05/22/2012 01:03 PM, Michael Meeks wrote: Even if you get the locking right -- even if absolutely only one thread is executing at once in your process -- like Paul said, you still get behavior that at a minimum freezes your window, and in other cases can act a lot like memory corruption. Sure I can believe gtk+ is broken currently in this regard. However my contention is that this is not an inevitable problem for gtk+ caused by the windows API. It is -possible- to get the gtk+ model to work, well, on windows. VCL does it today with a very similar locking model to the one gtk+ has used (again without using gtk+). I would also point out that VCL is not a top-flight, well-maintained, documented, high-quality toolkit with dozens of people working on it either ;-) If you have more details/links on how VCL gets around this, I'd be interested. A bit of a morbid curiosity perhaps :P Perhaps VCL isn't generic enough to run into this problem? Or is it solved by handing off all OS window creation in the main thread? Or running multiple windows message loops, and passing off received data to a main loop in another thread? Or perhaps it's just by chance that the problem hasn't been encountered during regular usage patterns? Seems like these would be pretty hacky solution for a general purpose toolkit like GTK+ to do. Or has VCL found a more correct solution to the problem? Again, asking out of interest here, as this has been a big obstacle for me several times over the years. So the it is fundamentally impossible to do argument seems just a bit weak from my perspective, I read it as it is easier not to do, and it's better to make our API users do the work instead ;-) which is rather different. Right, obviously not fundamentally impossible (given Turing completeness and all that) ... the issue is whether it's possible to do in a general purpose and correct way. Cheers, Stef ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
g_filename_to_uri() issue in glib-win32
I'm using the Glib function g_filename_to_uri() in glib-win32 (version 2.24). According to the documentation I should pass in a file path in the encoding format used by Glib (which on Windows is UTF-8). However, if I pass in a UTF-8 string, this function translates it character-by-character (as if it was plain ASCII). i.e. it doesn't recognise that the string is UTF-8. So for example, if the input string is Göran (encoded as UTF-8) I get the wrong output (hopefully, you can see that the 'o' has an umlaut). g_filename_to_uri encodes 6 characters and returns G%C3%B6ran instead of encoding just 5 characters to return the correct URI string G%F6ran. I can work around the problem by filtering my string through g_locale_from_utf8() before sending it to g_filename_to_uri() but I think that g_filename_to_uri() should be doing that for itself (either that - or the documentation's wrong). Can anyone confirm if this is a bug or intended behaviour? If it's a bug, is it fixed yet in the latest glib version? Thanks though for an otherwise great product. John Emmas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_filename_to_uri() issue in glib-win32
2012/5/22 John Emmas john...@tiscali.co.uk: So for example, if the input string is Göran (encoded as UTF-8) I get the wrong output (hopefully, you can see that the 'o' has an umlaut). g_filename_to_uri encodes 6 characters and returns G%C3%B6ran instead of encoding just 5 characters to return the correct URI string G%F6ran. What you get is an URI encoding of the UTF-8 bytes. I think this is the expected and correct behavior: there are multiple incompatible locale encodings and there's no way for this function to know what encoding you want to use for the URI. It would also fail if you had characters not representable in the locale encoding. This is at most a documentation bug. It should be stated that this function converts the string byte-by-byte, and everything outside of the 0-127 range is converted to hex escapes. (I think this is the only sensible behavior for this function.) Regards, Krzysztof ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_filename_to_uri() issue in glib-win32
On 23 May 2012, at 00:22, Krzysztof Kosiński wrote: What you get is an URI encoding of the UTF-8 bytes. I think this is the expected and correct behavior: there are multiple incompatible locale encodings and there's no way for this function to know what encoding you want to use for the URI. It would also fail if you had characters not representable in the locale encoding. This is at most a documentation bug. It should be stated that this function converts the string byte-by-byte, and everything outside of the 0-127 range is converted to hex escapes. Thanks for the prompt reply Krzysztof, I can see where you're coming from on this but there's another way to look at it. In my example (Göran) the UTF-8 byte sequence (for my particular code page) would have been:- 47 C3 B6 72 61 6E This would get displayed as:- G [ some codepage dependent character ] r a n But whatever that (second) character looked like, it's decimal value would always be 246 (because the UTF-8 sequence C3 B6 translates to decimal 246). The URI translation of decimal 246 is %F6. Therefore it should be possible to translate from UTF-8 [47 C3 B6 72 61 6E] into URI G%F6ran regardless of the user's code page. On my system this would say Göran whereas on someone else's system it might look different but that's not really relevant. The conversion itself is valid and shouldn't be affected by code pages. Code pages will only affect the displayed appearance. Of course, this is only with my simple example. There might be other examples where my theory breaks down. I've only considered this particular case. But if what you said was true Krzysztof, g_filename_to_utf8() would suffer from the same problem - but it doesn't. If (on Windows) you pass it a UTF-8 filename, it correctly recognises that the name is already UTF-8 and returns the original string (i.e. it doesn't attempt a new byte-by-byte conversion). So 'g_filename_to_uri()' is misbehaving AFAICT. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
