after i use the do-release-upgrade to upgrade from 12.10 to 13.04. the hime and gcin no longer work. just ibus can work. is there any package or config i need to remove in 13.04? or this is a bug in 4.10.2 13.04 version? Reproducible: Always
This gcin input method server is not created by the KDE community. For help, please ask in the forums of your distribution at http://ubuntuforums.org/ If you believe there is a bug, please report any issues related to gcin directly to the bug tracker of your distribution via https://bugs.launchpad.net/ubuntu
i have found the bug of this problem. it seems the .gtkrc-2.0 config has something error with the hime. and i found that file is create by the kde gtk config. is this kde problem or the input method problem?
> is create by the kde gtk config Can you be more specific what you do to create the broken .gtkrc file?
Created attachment 79489 [details] this is the config that cause the hime could not start. if this config remove or let it broken. the hime turn normal.
i also try the livecd kubuntu. it will cause this problem too. because the ubuntu unity did not has oxygen style. so i did not try.
Bugs for the GTK configuration in System Settings are not tracked at the KDE bug tracker, because the GTK configuration module is a distribution-specific add-on. Please report this issue directly to the bug tracker of your distribution via https://bugs.launchpad.net/ubuntu Other than that, I fail to see any error in the attached .gtkrc configuration file. If other components fail to correctly initialize because of this file, they are probably disabled by default, and need to be enabled in the .gtkrc file.
i am i little sure about the gtk error. when i change the style to the Raleigh, which is the gtk default on the kde. and the hime error is gone. are you sure that is not the kde problem?
and the .xsession-error is continue show this message QPixmap: It is not safe to use pixmaps outside the GUI thread
this is the error maybe opening the gtk config systemsettings(332)/kcontrol KCModuleLoader::loadModule: This module still uses K_EXPORT_COMPONENT_FACTORY. Please port it to use KPluginFactory and K_EXPORT_PLUGIN.
and since upgrade to the 13.04. the kde has crash frequently because of the gtk.
i have found the error in the oxygen-engines-gtk the settings. gtkrc file inside " style "oxygen-default" " " engine "oxygen-gtk" {} " this two line cause the gtk engine error. without this two line. the hime work normal
we need a backtrace of what is really causing the failure to start. Can you try run hime and gcin from gdb, then "bt" (after the program crashed), and post the result here ? Also: what is the version of oxygen-gtk that you are using ?
actually it did not crash. it just hang. that why i did not upgrade the crash report :((
ok. That is harder to help debug. still need the version of oxygen-gtk :) and if you feel daring, you can always try to download and build the latest version of oxygen-gtk from source (it is not difficult I promise). See: http://kde-look.org/content/show.php/?content=136216 There is a chance that the bug was fixed since then (although the version of oxygen-gtk above would help double-checking that).
... note that I can't reproduce, here at least hime starts just fine, as seed at: http://wstaw.org/m/2013/04/29/plasma-desktopay2362.png
(In reply to comment #15) > ... note that I can't reproduce, here at least hime starts just fine, as > seed at: > http://wstaw.org/m/2013/04/29/plasma-desktopay2362.png you can put my .gtkrc-2.0 in the home directory. and try again. this bug is only appear on the 13.04. and it seems cause my the engine in the grkrc.
by the engine. i input the wrong word.
yes, that is the engine I am using, oxygen-gtk (which conditions the appearance of the application).
(In reply to comment #18) > yes, that is the engine I am using, oxygen-gtk > (which conditions the appearance of the application). also use my .gtkrc-2.0 and kde-config-gtk ?
yes. But I use latest version of oxygen-gtk. Hence my asking about the version you are using.
ii gtk2-engines-oxygen:amd64 1.3.1-0ubuntu1 amd64 Oxygen widget theme for GTK+-based applications ii gtk3-engines-oxygen:amd64 1.1.1-0ubuntu1 amd64 Oxygen widget theme for GTK3-based applications maybe you can try the kubuntu iso. i install from that. and i have try in the livecd. it will cause that problem too.
by the way, what OS did you use?
no I will not. These versions are obsolete, and wont be fixed. Latest bugfix releases are 1.3.3 for gtk2-engine, and 1.1.3 for gtk3-engine. Please confirm whether or not the bug is still present with these versions. (either ask around for packages for these in ubuntu forums, or build them manually). As for the second question: I use mageia, but that is irrelevant. As one of the two developpers of oxygen-gtk, I use only the latest code, compile from source, manually. Cheers, Hugo
1.3.3 but i use the ppa or offical release is 1.3.1. only 1.3.1 could install. could you offer a url that could install or build.
i see the 1.3.3 version. actually the version i installed is 1.3.2.1. i have build by myself. and now i will build the 1.3.3 to try.
is it need to restart the computer or restart anything ?
it still cound not start. i also file a bug on the ubuntu. bug according to no crash report. so i do not think they will bother me.
in principle, nope now, if you are using a 64 bits machine, make sure that the libraries are installed in /usr/lib64/gtk-2.0/2.10.0/engines/ and not in /usr/lib/gtk-2.0/2.10.0/engines/ you might need to add -DLIB_SUFFIX=64 as an extra option to cmake, before compiling.
it auto detect is install in /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines :))
is there any IRC or anything could online chat?
yes, also could not start either.
ok. Since you have the source code built, and if you are willing to help tracking this down (thanks!), then you could try compile in debug mode, then start hime from a terminal (konsole), and post the output on screen here. To compile in debug mode: cmake -DOXYGEN_DEBUG=1 As for IRC, #oxygen is the right channel, but sadly I have no time these days to log on it, so that it would not help much. (hugo_work is my nick) Keep me posted concerning the above. Hugo
there are a problem. i still did not see the debug XDDDD. where did it output .xsession-error ?
and the gcin has the same problem with the oxygen gtk
and this is the bug report that file by me. because there is no run error. so i did not know that if he could see this bug. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173028
the debug output should appear in the same terminal as the one from where you started hime. if not it might mean that you are not using the oxygen-gtk version you just compiled. to make sure of that, try run "oxygen-gtk-demo" from the same terminal and report if you see some debug output there. You should see a lot. Things like: Oxygen::draw_flat_box - widget: 0x1061110 (GtkIconView) state: selected shadow: none detail: icon_view_item Oxygen::draw_layout - widget: 0x1061110 (GtkIconView) state: active detail: cellrenderertext ...
i see the output Oxygen::theme_init Oxygen::RCStyle::registerType Oxygen::StyleWrapper::registerType Oxygen::StyleWrapper::registerType - done Oxygen::Style::instance - creating new style. Oxygen::StyleHelper::StyleHelper Oxygen::Animations::Animations Oxygen::ArgbHelper::ArgbHelper Oxygen::ShadowHelper::ShadowHelper Oxygen::WindowManager::WindowManager Oxygen::StyleHelper::initializeRefSurface - screen: 0x1835000 window: 0x183f000 ApplicationName::initialize - from pid: hime_ from gtk: hime_ ApplicationName::initialize - from pid: hime_ from gtk: hime_ internal: Unknown version: 0x0
and this is gcin. Oxygen::theme_init Oxygen::ThemingEngine::registerType Oxygen::create_engine Oxygen::ThemingEngine::classInit Oxygen::ThemingEngine::instanceInit Oxygen::StyleHelper::StyleHelper Oxygen::Animations::Animations Oxygen::ArgbHelper::ArgbHelper Oxygen::ShadowHelper::ShadowHelper Oxygen::WindowManager::WindowManager Oxygen::StyleHelper::initializeRefSurface - screen: 0xa6c0d0 window: 0xa78000
thanks for the output. Now, this is strange, and very early during startup. For the record: what is the version of hime that you are using ?
(here I have installed 0.9.10)
(PS: I can start gcin just fine too. See: http://wstaw.org/m/2013/04/29/plasma-desktopIo2362.png)
same of your version. download from the network. and the gcin version is the offical verion 2.7.6
my kde using the color obsidian coast so that i could figure out that the gtk is using the oxygen theme or not :)))
I can't start gcin in Ubuntu 13.04 either. But even if I select GTK themes as Raleigh or Emacs, it doesn't start too. Also, in Ubuntu 13.04 at least, gcin is linked to gtk3 not gtk2.
OK. I can reproduce the problem with gcin. On correct startup it just makes tray icons, but doesn't show any windows - this is why I thought it doesn't start. Now I can see that oxygen-gtk makes it not start. Here's a backtrace: http://pastebin.com/wfhpKRis
Hime backtrace is similar despite it's gtk2 based. Here's an updated backtrace from gcin with debug symbols and current git oxygen-gtk3: http://pastebin.com/yTrKygMV
ok. So g_spawn_command_line_sync is the bad guy this might actually be a glib issue, and not oxygen-gtk What is the version you guys are using ? Then we would need a workaround. We use g_spawn to get the list of kde config path, to look for configuration files. This is a way to launch eternal processes (here kde4-config) and wait for the result before proceceeding.
(I have glib-2.34.3)
reading the backtrace, you have glib 2.36 or so. ... that might explain. Ruslan, any chance you can rollback or test on another computer ? I'll try to update glib on my side (but likely not this evening).
My glib version is 2.36.0. I've tried changing kde4-config command to true and asdfasdfadf, but it fails in the same way. I in fact doubt it's a glib issue. I'd rather suspect the way these apps use threads. There might be some condition when we must not start any processes, but I'm not a threading guru and may be wrong.
@Ruslan, yeah well, but I can't reproduce the issue on my side. So not only the app, but "something else" at least must enter the game ... I agree this is unlikely glib only otherwise all gtk applications would stop to work, since we use this all the time.
Note: we could try use the good old "popen" command. That should not never fail
I've tested on Ubuntu 12.04.2 LTS with glib 2.32.3 and both apps work here (and gcin is gtk2-based here).
OK, popen does do the trick. I guess I'll clean it up and push.
awesome ! Thanks !
Git commit 51b662b0cd86fd7a960cc2f0c436441d64b2dd44 by Ruslan Kabatsayev. Committed on 29/04/2013 at 21:24. Pushed by kabatsayev into branch 'gtk3'. Use popen instead of g_spawn_command_line_sync() M +18 -2 src/oxygenqtsettings.cpp M +3 -0 src/oxygenqtsettings.h http://commits.kde.org/oxygen-gtk/51b662b0cd86fd7a960cc2f0c436441d64b2dd44
Git commit a515ab451f54cbc930d0a09d250669255dd8a741 by Ruslan Kabatsayev. Committed on 29/04/2013 at 21:24. Pushed by kabatsayev into branch '1.3'. Use popen instead of g_spawn_command_line_sync() M +18 -2 src/oxygenqtsettings.cpp M +3 -0 src/oxygenqtsettings.h http://commits.kde.org/oxygen-gtk/a515ab451f54cbc930d0a09d250669255dd8a741
Git commit 5e22bbf8bf09663f2be9cd7510a956fc5ad4faba by Ruslan Kabatsayev. Committed on 29/04/2013 at 21:24. Pushed by kabatsayev into branch 'gtk3-1.1'. Use popen instead of g_spawn_command_line_sync() M +18 -2 src/oxygenqtsettings.cpp M +3 -0 src/oxygenqtsettings.h http://commits.kde.org/oxygen-gtk/5e22bbf8bf09663f2be9cd7510a956fc5ad4faba
@l12436@yahoo.com.tw Please check if the bug is fixed for both apps and if yes, close this as fixed. @Hugo Please have a look at the patch, just in case I messed up ;)
will do
@Ruslan will check it likely needs some improvements, to accomodate "all" sizes as opposed to fixed size. but I have the relevant code in place. current patch is good enough for the time being (and technically correct), i'll just ellaborate upon this. Thanks a bunch to go to the bottom of it.
thanks for help. it work normal as usual. the fatal problem is solve :))) actually there another problem. but no so fatal. the libreoffice could not change its style. it lock in oxygen :))) i still find that why cause that problem.
because i did not know that the how to choose the option. so i just change the confirm to resolved, the second i keep it on the first option.
and one thing ask. is the fix version will in the ubuntu offical package release? change the 1.3.1 to the newer version ?
and maybe you can contract the kde team that the g_spawn_command_line_sync bug
one thing to ask, the three patch has different ?
> the libreoffice could not change its style. Libreoffice is not related to KDE, it just uses some of its theme plugins which use Qt or GTK to render widgets. > is the fix version will in the ubuntu offical package release? We'll have to release this patch in a new version, then it depends on Ubuntu packagers whether they will take it and update their packages. > and maybe you can contract the kde team that the g_spawn_command_line_sync bug g_spawn_command_line_sync() is not related to KDE - it's a glib function. > the three patch has different ? These are patches in different branches, they are identical. It's just the way git-cherry-pick works, so that this was posted three times here for each copy of patch.
>g_spawn_command_line_sync() is not related to KDE - it's a glib function. i mean that you could contract the kde team that the g_spawn_command_line_sync() has bug. and tell the software maintainer to change the code.
and tell the software maintainer to change the code.(X and tell the software maintainer to prevent using that function.
> i mean that you could contract the kde team that the g_spawn_command_line_sync() has bug. It's likely not that this function has the bug. It may well be that it shouldn't be called when we do because of something special gcin and hime do before our method is called. Oxygen-GTK, unfortunately, has many such invalid assumptions (but we might not know of their invalidity), which it has to do in order to implement the features we need. It's just a matter of complexity of features we put into it.
it seems the qtcurve has the same bug, too. i am not sure. i have try once. and it not start either.
> it seems the qtcurve has the same bug, too. Yeah, it should. It also uses this function. So you should report it to Craig (and point to possible fix here). Though he might instead devise some wittier fix :)
Git commit 592490ea8d7dcd328b755cbb28b9be205d68168f by Hugo Pereira Da Costa. Committed on 30/04/2013 at 14:18. Pushed by hpereiradacosta into branch '1.3'. Make sure that 'runCommand' reads the full output of the command (as opposed to fixed max size); Changed first argument to std::string. M +19 -9 src/oxygenqtsettings.cpp M +1 -1 src/oxygenqtsettings.h http://commits.kde.org/oxygen-gtk/592490ea8d7dcd328b755cbb28b9be205d68168f
Git commit a8b7085a657bd7f27978c3a2765310758382e60d by Hugo Pereira Da Costa. Committed on 30/04/2013 at 14:18. Pushed by hpereiradacosta into branch 'gtk3'. Make sure that 'runCommand' reads the full output of the command (as opposed to fixed max size); Changed first argument to std::string. M +19 -9 src/oxygenqtsettings.cpp M +1 -1 src/oxygenqtsettings.h http://commits.kde.org/oxygen-gtk/a8b7085a657bd7f27978c3a2765310758382e60d
@Ruslan Last two commits are just some tiny improvements upon your addition, to make sure the entire output of the comment is read. I have tested it works by reducing the initial size of the buffer to 16 and making sure one gets the same output. Thanks again for the fix. @l12436 Thanks for reporting the issue in the first place.
@Hugo Pereira Da Costa > @l12436 > Thanks for reporting the issue in the first place. you're welcome. this problem cause me a lot of trouble. i hope it could fix before the 4.10.3 release :) >Yeah, it should. It also uses this function. So you should report it to Craig (and point to possible fix here). Though he might instead devise some wittier fix :) ok, the bug report website is the same website, isn't it. :)) just change the report software. :))
@Hugo Mm.. what's the point in converting char* to std::string just to then convert back to char* when calling popen? Looks like unnecessary redundancy to me. @l12436 > ok, the bug report website is the same website, isn't it. :)) No it's not. AFAIK, QtCurve isn't related to KDE at all, especially its GTK part.
and one thing i need to ask. how to create the runtime report like this http://pastebin.com/wfhpKRis i have try the gdb, but it only show the simple information. or even no information.
@Hugo BTW, setting size=4 instead of 4096 reveals that your improvement doesn't quite work, see output of result after fgets (repeated because of while loop): result: "/home/r" result: "uslan/.kde/shar" result: "e/config/:/opt/kde4/share/confi"
@l12436 You just run the app like "gdb -ex r hime", wait until it settles, then press Ctrl+C to interrupt. Now you can do backtrace from the stage you interrupted the process. If the process is hung, you'll surely interrupt it somewhere where it loops.
it need to install the addition package ? i use the command too. it only show the interrupted.
@l12436 Can you use gdb, namely get the backtrace? See the pastebin example - it starts from ^C, which is where I pressed Ctrl+C, then you can see how to get the backtrace (bt command).
thanks for teaching. now i got the backtrace too
Git commit 878b0e626311cdf847e00dfd6ff96184021c1667 by Ruslan Kabatsayev. Committed on 30/04/2013 at 17:05. Pushed by kabatsayev into branch '1.3'. Fix command output reading for multi-read case M +8 -6 src/oxygenqtsettings.cpp http://commits.kde.org/oxygen-gtk/878b0e626311cdf847e00dfd6ff96184021c1667
Git commit f272b269cd26e783ffb811c4a3584a675fac7a2b by Ruslan Kabatsayev. Committed on 30/04/2013 at 17:05. Pushed by kabatsayev into branch 'gtk3'. Fix command output reading for multi-read case M +8 -6 src/oxygenqtsettings.cpp http://commits.kde.org/oxygen-gtk/f272b269cd26e783ffb811c4a3584a675fac7a2b
(In reply to comment #85) > Git commit f272b269cd26e783ffb811c4a3584a675fac7a2b by Ruslan Kabatsayev. > Committed on 30/04/2013 at 17:05. > Pushed by kabatsayev into branch 'gtk3'. > > Fix command output reading for multi-read case > > M +8 -6 src/oxygenqtsettings.cpp > > http://commits.kde.org/oxygen-gtk/f272b269cd26e783ffb811c4a3584a675fac7a2b i see the repo not found
Yeah, me too. Maybe will appear later. You still can pull it in your local git and see the diff there.
@Ruslan Thanks for fixing. My bad. Too bad I was fixing at the same time. So now: using size *=2, rather than incrementing linearly the size is known to be more efficient algorithmically. So I'd rather push that. (will do on top of your changes after first discarding the ones I was about to push) Concerning the use of std::string. There is No conversion from const char* to std::string in the current code the call runCommand( "..." ) implicitely calls the std::string directly as for the call string.c_str() it access directly the const char* stored internally in the string the advantage of using std::string instead of const char* is that it is freed automatically. You do not need to call neither malloc nor free anywhere. In the current code it makes no difference (but not overhead either), but it might makes some future use of the same method. All in all, that's the whole idea behind using c++ instead of c, and limit c to where you have to (namely when calling gtk, glib or other functions).
i fix by manual :))))
> So now: using size *=2, rather than incrementing linearly the size is known to be more efficient algorithmically. Yeah, surely, but with chunks of 512 bytes this isn't gonna increase much more than to 2KiB, so this inefficiency can be neglected in favor of cleaner code. > There is No conversion from const char* to std::string in the current code > the call runCommand( "..." ) implicitely calls the std::string directly > as for the call string.c_str() it access directly the const char* stored internally in the string Why no conversion? You call runCommand("str") and this calls std::string("str") potentially doing some initialization there. And then you call a function which needs const char*, in which case although you don't convert, but this still is redundant. > All in all, that's the whole idea behind using c++ instead of c, and limit c to where you have > to (namely when calling gtk, glib or other functions). Yeah I do understand this, but you have a POSIX function here - this is just like gtk function, and we pass string literal here, for which std::string has no advantage at all.
(In reply to comment #90) > > So now: using size *=2, rather than incrementing linearly the size is known to be more efficient algorithmically. > Yeah, surely, but with chunks of 512 bytes this isn't gonna increase much > more than to 2KiB, so this inefficiency can be neglected in favor of cleaner > code. Depends how long the string you want to read, right ? in principle runCommand could be re-used elsewhere for any type of command (like "cat very_long_file_with_no_linebreak") > > > There is No conversion from const char* to std::string in the current code > > the call runCommand( "..." ) implicitely calls the std::string directly > > as for the call string.c_str() it access directly the const char* stored internally in the string > Why no conversion? You call runCommand("str") and this calls > std::string("str") potentially doing some initialization there. yes the initialization of the extra members of std::string on top of the const char* (which is kept unchanged, passed as a pointer). > And then you > call a function which needs const char*, in which case although you don't > convert, but this still is redundant. redundant with what ? std::string is a pointer to const char* with a proper destructor and copy constructor. Nothing more. (well, more or less :)) > > > All in all, that's the whole idea behind using c++ instead of c, and limit c to where you have > > to (namely when calling gtk, glib or other functions). > Yeah I do understand this, but you have a POSIX function here - this is just > like gtk function, and we pass string literal here, for which std::string > has no advantage at all. But that's the point: disregarding of the internals of the function, I don't want it to spread. I do not what to have to ask myself, every time I call runCommand, whether I need to free the string or not (disregarding whether it uses posix or gtk in there). The idea is not about what's done internally, but what to expect when called by the rest of the world, without knowing what's done internally. With passing std::string, I know I don't have to care about allocation deallocation. That's the same spirit behind my writting of the oxygencairosurface, pattern, context; the timers, etc. In general, the more "self-deallocating" things you use for the arguments in your methods, the more stable your code will be. (my oppinion at least) In any case, I'm not sure here is the right place to have this discussion.
> yes the initialization of the extra members of std::string on top of the const char* (which is kept unchanged, passed as a pointer). It's copied in fact. You thus have first copy - a string literal, and second one - created in constructor. That's why my objection. Even though I recognize that command line is negligible in size, this way of handling string literals is just unclean. And you don't need to worry about deletion since you can use std::string in caller and then pass it like mycmd.c_str() to runCommand(). In general, I do agree about using self-deallocating objects, but this case doesn't really look like the one which really needs this. Anyway, if you still aren't convinced, then I won't argue anymore and will agree to have it left alone.
Are there any plans of a new release with these patches anytime soon? This bug breaks using emacs with oxygen-gtk2 after upgrading libglib to version 2.36 in Debian. That update is already in unstable, so it will probably migrate to testing soon and start hitting Debian testing desktop users.
Comming back to this bug, because I am not happy with the use of popen (which is less portable than g_spawn): testing with g_spawn again and glib-2.36.2, I do not get the issue anymore. could someone double check ? (would require some oxygen-gtk checked-out at, e.g. a515ab451f54cbc930d0a09d250669255dd8a741^ and build from source, for gtk2 applications.)
... digging: https://bugzilla.gnome.org/show_bug.cgi?id=698081 seems, it was indeed a glib bug, that got fixed in glib. I would be inclined to revert this change to popen, and close (again) this bug as upstream. Ruslan ? oppinion ?
> Ruslan ? oppinion ? Well, I'd in fact rather use "#define popen _popen" etc. on Windows (if this is what you mean by portability), not return to glib-specific code. popen() is much less likely to fail, and this is why I'd prefer using it instead.
@Ruslan problem with popen: - it is defined on windows (with mingw at least) and works, but opens a terminal to execute a command. (not so nice). And I'm not sure _popen would fix this, would it ? - on unix, it does not allow to easily redirect stderr, so you get an error message (for every application) when kde4-config is not installed. So that I had to add a 2> /dev/null (committed), to hide the (armless) error message, in current master, because users were already complaining. But this, in turn, is not portable to windows. All this is nicely handled in g_spawn, when it works ... popen being more likely to work on windows depends on MinGW (not even sure if it is implemented with VC ...). While g_spawn depends on glib. Which one is more error prone I do not know (I would assume glib, but ...) So bottomline: if we want to stick to popen (to be more glib-error safe), we'd likely need more code (and more #ifdef) than what we have now ...
PS: maybe we can revert the change in popen, in master only ... (which will become our next feature release) ?
> - it is defined on windows (with mingw at least) and works, but opens a terminal to execute a command. (not so nice). And I'm not sure _popen would fix this, would it ? Most likely it won't. But we can make something like this: #ifdef _WIN32 ShowWindow(GetConsoleWindow(),SW_HIDE); #endif before running popen(). (Ugly, but should do the trick.) > - on unix, it does not allow to easily redirect stderr, so you get an error message (for every application) when kde4-config is not installed. So that I had to add a 2> /dev/null (committed), to hide the (armless) error message, in current master, because users were already complaining. This is more serious. Not sure how to fix this well enough... > popen being more likely to work on windows depends on MinGW (not even sure if it is implemented with VC ...). _popen() is listed in MSDN, so this one should be available with VC. > So bottomline: if we want to stick to popen (to be more glib-error safe), we'd likely need more code (and more #ifdef) than what we have now ... Yeah, hard to decide. Seems you're right and we should go back to glib. (But we should make sure this doesn't break any distro again if they still use unfixed glib version).
@Ruslan So I'd suggest: - keep current branches as they are (with popen). - revert the change (sort of: I would like to keep the RunCommand method :)) for master (and gtk3 branch). - if we want to be extra sure, add a minimal requirement on the glib version in our (master) CMakefiles. What do you think ?
> if we want to be extra sure, add a minimal requirement on the glib version in our (master) CMakefiles. No, that's bad. This way you'll disable any older distros from being able to use latest oxygen-gtk release. I'd suggest that we leave both variants - via popen() and g_spawn...() - and use popen() only for that glib version(s) which fails (and warn user in cmake output that current glib version is bad).
yeah well. More ifdefs ... not sure I want that. Especially if it is to bypass a bug that is present in only one _minor_ release of glib. The only advantage of keeping popen is if other (future) versions of glib break, which the suggestion you propose would not prevent either ... So in the end, gspawn it should be, and gspawn only, I'd say, assuming that upstream is reliable. (especially a low level library such as glib) And too bad for the systems running with broken glib (in fact, I expect that if it also breaks pidgin, distros would be quite quick at patching glib)
Git commit ccf7f9c46e521f3966751cbf822beb242579abe3 by Hugo Pereira Da Costa. Committed on 19/06/2013 at 12:17. Pushed by hpereiradacosta into branch 'gtk3'. Re-added use of g_spawn_command_line_sync in place of popen, to execute an external comment. This effectively reverts commit 51b662b0cd86fd7a960cc2f0c436441d64b2dd44 Rational: - the failure of g_spawn_command_line_sync was a glib bug 3.6.0, that got fixed since then (3.6.2) - the use of popen generates unnecessary console when compiled for windows - the use of popen makes it difficult to redirect stderr, which results in error messages being printed on screen when the executed command failed (for instance because the relevant application is not installed. M +3 -26 src/oxygenqtsettings.cpp http://commits.kde.org/oxygen-gtk/ccf7f9c46e521f3966751cbf822beb242579abe3
Git commit 2068101234271725def6fe91de4a26543b260cba by Hugo Pereira Da Costa. Committed on 19/06/2013 at 12:17. Pushed by hpereiradacosta into branch 'master'. Re-added use of g_spawn_command_line_sync in place of popen, to execute an external comment. This effectively reverts commit 51b662b0cd86fd7a960cc2f0c436441d64b2dd44 Rational: - the failure of g_spawn_command_line_sync was a glib bug 3.6.0, that got fixed since then (3.6.2) - the use of popen generates unnecessary console when compiled for windows - the use of popen makes it difficult to redirect stderr, which results in error messages being printed on screen when the executed command failed (for instance because the relevant application is not installed. M +3 -26 src/oxygenqtsettings.cpp http://commits.kde.org/oxygen-gtk/2068101234271725def6fe91de4a26543b260cba
the 1.3.3 gtk engine in my system will cause stcok from the konsole to the whole kde GUI when i use the ctrl + z to try to move the hime to the background. so i still decide to use the fix version.
the 1.3.3 gtk engine in my system will cause stock from the konsole to the whole kde GUI when i use the ctrl + z to try to move the hime to the background. so i still decide to use the fix version.
because the konsole got stock, i can not be able get the backtrace. even use the another konsole to open the new konsole.
is this bug still valid ? It requires a recent enough version of glib, for g_spawn to be working properly.
now is fixed, i did not know why is reopened
thanks. Closing then