← Back to team overview

ubuntu-elisp team mailing list archive

[Bug 1142213] Re: emacs23/24 GUI does not start when run in Kubuntu 13.04 with oxygen-gtk theme enabled

 

Launchpad has imported 94 comments from the remote bug at
https://bugs.kde.org/show_bug.cgi?id=318891.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2013-04-26T03:48:46+00:00 TomHarrison wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/15

------------------------------------------------------------------------
On 2013-04-26T04:51:48+00:00 Christoph-maxiom wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/16

------------------------------------------------------------------------
On 2013-04-27T03:11:19+00:00 TomHarrison wrote:

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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/17

------------------------------------------------------------------------
On 2013-04-27T07:53:12+00:00 Christoph-maxiom wrote:

>  is create by the kde gtk config

Can you be more specific what you do to create the broken .gtkrc file?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/18

------------------------------------------------------------------------
On 2013-04-27T09:40:13+00:00 TomHarrison wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/19

------------------------------------------------------------------------
On 2013-04-27T10:25:11+00:00 TomHarrison wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/20

------------------------------------------------------------------------
On 2013-04-27T19:54:19+00:00 Christoph-maxiom wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/21

------------------------------------------------------------------------
On 2013-04-28T13:15:20+00:00 TomHarrison wrote:

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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/22

------------------------------------------------------------------------
On 2013-04-28T13:16:39+00:00 TomHarrison wrote:

and the .xsession-error is continue show this message
QPixmap: It is not safe to use pixmaps outside the GUI thread

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/23

------------------------------------------------------------------------
On 2013-04-28T13:38:45+00:00 TomHarrison wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/24

------------------------------------------------------------------------
On 2013-04-28T14:31:14+00:00 TomHarrison wrote:

and since upgrade to the 13.04.
the kde has crash frequently because of the gtk.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/25

------------------------------------------------------------------------
On 2013-04-29T00:41:31+00:00 TomHarrison wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/28

------------------------------------------------------------------------
On 2013-04-29T12:05:58+00:00 Hugo Pereira Da Costa wrote:

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 ?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/32

------------------------------------------------------------------------
On 2013-04-29T12:31:42+00:00 TomHarrison wrote:

actually it did not crash.
it just hang.
that why i did not upgrade the crash report :((

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/33

------------------------------------------------------------------------
On 2013-04-29T12:42:13+00:00 Hugo Pereira Da Costa wrote:

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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/34

------------------------------------------------------------------------
On 2013-04-29T12:45:50+00:00 Hugo Pereira Da Costa wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/35

------------------------------------------------------------------------
On 2013-04-29T13:01:59+00:00 TomHarrison wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/36

------------------------------------------------------------------------
On 2013-04-29T13:04:32+00:00 TomHarrison wrote:

by the engine.
i input the wrong word.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/37

------------------------------------------------------------------------
On 2013-04-29T13:13:45+00:00 Hugo Pereira Da Costa wrote:

yes, that is the engine I am using, oxygen-gtk
(which conditions the appearance of the application).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/38

------------------------------------------------------------------------
On 2013-04-29T13:16:05+00:00 TomHarrison wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/39

------------------------------------------------------------------------
On 2013-04-29T13:17:34+00:00 Hugo Pereira Da Costa wrote:

yes.
But I use latest version of oxygen-gtk.
Hence my asking about the version you are using.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/40

------------------------------------------------------------------------
On 2013-04-29T13:21:29+00:00 TomHarrison wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/41

------------------------------------------------------------------------
On 2013-04-29T13:25:28+00:00 TomHarrison wrote:

by the way, what OS did you use?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/42

------------------------------------------------------------------------
On 2013-04-29T13:27:25+00:00 Hugo Pereira Da Costa wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/43

------------------------------------------------------------------------
On 2013-04-29T13:38:48+00:00 TomHarrison wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/44

------------------------------------------------------------------------
On 2013-04-29T13:50:11+00:00 TomHarrison wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/45

------------------------------------------------------------------------
On 2013-04-29T13:52:33+00:00 TomHarrison wrote:

is it need to restart the computer or restart anything ?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/46

------------------------------------------------------------------------
On 2013-04-29T13:54:20+00:00 TomHarrison wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/47

------------------------------------------------------------------------
On 2013-04-29T13:55:00+00:00 Hugo Pereira Da Costa wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/48

------------------------------------------------------------------------
On 2013-04-29T13:57:48+00:00 TomHarrison wrote:

it auto detect is install in /usr/lib/x86_64-linux-
gnu/gtk-2.0/2.10.0/engines :))

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/49

------------------------------------------------------------------------
On 2013-04-29T13:58:26+00:00 TomHarrison wrote:

is there any IRC or anything could online chat?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/50

------------------------------------------------------------------------
On 2013-04-29T13:59:11+00:00 TomHarrison wrote:

yes, also could not start either.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/51

------------------------------------------------------------------------
On 2013-04-29T14:00:42+00:00 Hugo Pereira Da Costa wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/52

------------------------------------------------------------------------
On 2013-04-29T14:06:19+00:00 TomHarrison wrote:

there are a problem. i still did not see the debug XDDDD.
where did it output
.xsession-error ?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/53

------------------------------------------------------------------------
On 2013-04-29T14:09:41+00:00 TomHarrison wrote:

and the gcin has the same problem with the oxygen gtk

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/54

------------------------------------------------------------------------
On 2013-04-29T14:20:18+00:00 TomHarrison wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/55

------------------------------------------------------------------------
On 2013-04-29T14:26:35+00:00 Hugo Pereira Da Costa wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/56

------------------------------------------------------------------------
On 2013-04-29T14:34:23+00:00 TomHarrison wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/57

------------------------------------------------------------------------
On 2013-04-29T14:43:23+00:00 TomHarrison wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/58

------------------------------------------------------------------------
On 2013-04-29T14:55:32+00:00 Hugo Pereira Da Costa wrote:

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 ?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/59

------------------------------------------------------------------------
On 2013-04-29T14:56:19+00:00 Hugo Pereira Da Costa wrote:

(here I have installed 0.9.10)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/60

------------------------------------------------------------------------
On 2013-04-29T14:58:51+00:00 Hugo Pereira Da Costa wrote:

(PS: I can start gcin just fine too. See: http://wstaw.org/m/2013/04/29
/plasma-desktopIo2362.png)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/61

------------------------------------------------------------------------
On 2013-04-29T15:01:13+00:00 TomHarrison wrote:

same of your version.
download from the network.
and the gcin version is the offical verion
2.7.6

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/62

------------------------------------------------------------------------
On 2013-04-29T15:03:26+00:00 TomHarrison wrote:

my kde using the color obsidian coast
so that i could figure out that the gtk is using the oxygen theme or not :)))

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/63

------------------------------------------------------------------------
On 2013-04-29T17:33:54+00:00 Ruslan wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/65

------------------------------------------------------------------------
On 2013-04-29T18:33:36+00:00 Ruslan wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/66

------------------------------------------------------------------------
On 2013-04-29T18:43:32+00:00 Ruslan wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/67

------------------------------------------------------------------------
On 2013-04-29T18:48:02+00:00 Hugo Pereira Da Costa wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/68

------------------------------------------------------------------------
On 2013-04-29T18:48:45+00:00 Hugo Pereira Da Costa wrote:

(I have glib-2.34.3)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/69

------------------------------------------------------------------------
On 2013-04-29T18:50:38+00:00 Hugo Pereira Da Costa wrote:

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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/70

------------------------------------------------------------------------
On 2013-04-29T18:51:36+00:00 Ruslan wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/71

------------------------------------------------------------------------
On 2013-04-29T18:53:16+00:00 Hugo Pereira Da Costa wrote:

@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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/72

------------------------------------------------------------------------
On 2013-04-29T18:55:04+00:00 Hugo Pereira Da Costa wrote:

Note: we could try use the good old "popen" command. That should not
never fail

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/73

------------------------------------------------------------------------
On 2013-04-29T18:56:56+00:00 Ruslan wrote:

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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/74

------------------------------------------------------------------------
On 2013-04-29T19:06:56+00:00 Ruslan wrote:

OK, popen does do the trick. I guess I'll clean it up and push.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/75

------------------------------------------------------------------------
On 2013-04-29T19:07:45+00:00 Hugo Pereira Da Costa wrote:

awesome ! 
Thanks !

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/76

------------------------------------------------------------------------
On 2013-04-29T19:24:28+00:00 Ruslan wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/77

------------------------------------------------------------------------
On 2013-04-29T19:33:54+00:00 Ruslan wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/78

------------------------------------------------------------------------
On 2013-04-29T19:35:53+00:00 Ruslan wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/79

------------------------------------------------------------------------
On 2013-04-29T19:37:31+00:00 Ruslan wrote:

@l12436@xxxxxxxxxxxx
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 ;)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/80

------------------------------------------------------------------------
On 2013-04-29T19:54:01+00:00 Hugo Pereira Da Costa wrote:

will do

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/81

------------------------------------------------------------------------
On 2013-04-29T19:59:04+00:00 Hugo Pereira Da Costa wrote:

@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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/82

------------------------------------------------------------------------
On 2013-04-30T00:14:09+00:00 TomHarrison wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/83

------------------------------------------------------------------------
On 2013-04-30T00:16:26+00:00 TomHarrison wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/84

------------------------------------------------------------------------
On 2013-04-30T00:19:07+00:00 TomHarrison wrote:

and one thing ask.
is the fix version will in the ubuntu offical package release?
change the 1.3.1 to the newer version ?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/85

------------------------------------------------------------------------
On 2013-04-30T01:19:54+00:00 TomHarrison wrote:

and maybe you can contract the kde team that the
g_spawn_command_line_sync bug

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/86

------------------------------------------------------------------------
On 2013-04-30T01:25:11+00:00 TomHarrison wrote:

one thing to ask,
the three patch has different ?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/87

------------------------------------------------------------------------
On 2013-04-30T07:05:46+00:00 Ruslan wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/88

------------------------------------------------------------------------
On 2013-04-30T07:58:39+00:00 TomHarrison wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/89

------------------------------------------------------------------------
On 2013-04-30T07:59:54+00:00 TomHarrison wrote:

and tell the software maintainer to change the code.(X
and tell the software maintainer to prevent using that function.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/90

------------------------------------------------------------------------
On 2013-04-30T08:20:38+00:00 Ruslan wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/91

------------------------------------------------------------------------
On 2013-04-30T09:04:27+00:00 TomHarrison wrote:

it seems the qtcurve has the same bug, too.
i am not sure.
i have try once.
and it not start either.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/92

------------------------------------------------------------------------
On 2013-04-30T09:07:01+00:00 Ruslan wrote:

> 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 :)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/93

------------------------------------------------------------------------
On 2013-04-30T12:28:27+00:00 5w-hugo wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/95

------------------------------------------------------------------------
On 2013-04-30T12:28:27+00:00 5w-hugo wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/96

------------------------------------------------------------------------
On 2013-04-30T12:30:35+00:00 Hugo Pereira Da Costa wrote:

@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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/97

------------------------------------------------------------------------
On 2013-04-30T13:25:59+00:00 TomHarrison wrote:

@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. :))

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/98

------------------------------------------------------------------------
On 2013-04-30T13:27:31+00:00 Ruslan wrote:

@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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/99

------------------------------------------------------------------------
On 2013-04-30T13:34:02+00:00 TomHarrison wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/100

------------------------------------------------------------------------
On 2013-04-30T13:34:23+00:00 Ruslan wrote:

@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"

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/101

------------------------------------------------------------------------
On 2013-04-30T13:35:54+00:00 Ruslan wrote:

@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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/102

------------------------------------------------------------------------
On 2013-04-30T13:42:02+00:00 TomHarrison wrote:

it need to install the addition package ?
i use the command too.
it only show the interrupted.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/103

------------------------------------------------------------------------
On 2013-04-30T13:47:01+00:00 Ruslan wrote:

@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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/104

------------------------------------------------------------------------
On 2013-04-30T13:53:33+00:00 TomHarrison wrote:

thanks for teaching.
now i got the backtrace too

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/105

------------------------------------------------------------------------
On 2013-04-30T15:09:23+00:00 Ruslan wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/106

------------------------------------------------------------------------
On 2013-04-30T15:12:11+00:00 Ruslan wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/107

------------------------------------------------------------------------
On 2013-04-30T15:13:49+00:00 TomHarrison wrote:

(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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/108

------------------------------------------------------------------------
On 2013-04-30T15:16:26+00:00 Ruslan wrote:

Yeah, me too. Maybe will appear later. You still can pull it in your
local git and see the diff there.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/109

------------------------------------------------------------------------
On 2013-04-30T15:25:36+00:00 Hugo Pereira Da Costa wrote:

@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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/110

------------------------------------------------------------------------
On 2013-04-30T15:30:15+00:00 TomHarrison wrote:

i fix by manual  :))))

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/111

------------------------------------------------------------------------
On 2013-04-30T15:33:16+00:00 Ruslan wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/112

------------------------------------------------------------------------
On 2013-04-30T15:44:01+00:00 Hugo Pereira Da Costa wrote:

(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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/113

------------------------------------------------------------------------
On 2013-04-30T15:58:35+00:00 Ruslan wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/114

------------------------------------------------------------------------
On 2013-05-12T17:55:17+00:00 Ralf Jung wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/1142213/comments/120


** Changed in: emacs
       Status: Unknown => Fix Released

** Changed in: emacs
   Importance: Unknown => High

-- 
You received this bug notification because you are a member of Ubuntu
Emacs Lisp, which is subscribed to emacs23 in Ubuntu.
https://bugs.launchpad.net/bugs/1142213

Title:
  emacs23/24 GUI does not start when run in Kubuntu 13.04 with oxygen-
  gtk theme enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/emacs/+bug/1142213/+subscriptions