emacs23/24 and other GTK applications do not start when run in Kubuntu 13.04 with oxygen-gtk theme enabled

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
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 ?

@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