[opensuse-factory] M17N scim gtk help needed.
Hi, all, I need some gtk coding help to fix scim related packages in M17N repository. package status here: https://build.opensuse.org/project/monitor?blocked=0&building=0&dispatching=0&finished=0&project=M17N&scheduled=0&signing=0&succeeded=0 == Long version : == I updated scim main package to 1.4.13. You may never heard of this project. It's an old Input Method Framework project. Upstream indeed didn't maintain it for a long time They didn't claim it, but actually all Input Engine sub-packages can't be built against lastest IMF main package. it means they didn't maintain the input engine interfaces like scim-pinyin, scim-chewing, scim-anthy, scim-canna, scim-tables, scim-skk....all of them. So any upstream bug report will be "abandoned". Even if we can open and wait, openSUSE can't. Here's the situation: According to its maintenance status (inactive package maintainers in M17N and upstream, the latest SR against one of them is from coolo about 12 month ago), broken status and popularity among the users, we have made a deal to get rid of it from DVD. And I removed provides tag from scim main package. But, because of sub packages' broken status against Factory, I can't submit any SR against them. It means we may have about 10 broken dependency packages installed in openSUSE 12.2. ( newer version of scim, and old versions of all the others. they can't work together.) So possible solutions are: 1. Drop them completely. Since I fixed all the packages related to zh_CN locale, and I don't know how many people use it in other locales. I can't make such decision. And another reason is because SLE_11_SP2 is still using it. (SLE_11_SP2 is a longer supported version. if I drop them, it'll cause many problems to both SuSE staff and SLE users. Dependencies in SLE_11_SP2 are not new enough to build other IMF like IBus/Fcitx/Mozc/Gcin.) 2. Fix them and remove the provides tags from them. That's exactly I did. Some maintainers said just let scim die. but if we can let it die, we have already done. scim-anthy, scim-chewing and others didn't see any new release since 2006, we're still maintaining it. Because there're no other solutions in some of openSUSE derivatives. Now I have fixed: scim-pinyin, scim-unikey, scim-anthy, scim-hangul. I can't fix others because it's out of my effort. Some of the GTK functions and macros used in them are too old (GTK 2.12) and have no new alternatives. It means we have to rewrite some lines of its codes. like GTK_Fileselection to GTK_Dialog, GTK_combo to GTK_combobox. So if anyone have time and GTK coding experience, please offer some help. Greetings, Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Sun, 10 Jun 2012 19:55:03 +0800, Marguerite Su wrote:
Hi, all,
I need some gtk coding help to fix scim related packages in M17N repository.
package status here: https://build.opensuse.org/project/monitor?blocked=0&building=0&dispatching=0&finished=0&project=M17N&scheduled=0&signing=0&succeeded=0
== Long version : ==
I updated scim main package to 1.4.13.
You may never heard of this project. It's an old Input Method Framework project. Upstream indeed didn't maintain it for a long time
They didn't claim it, but actually all Input Engine sub-packages can't be built against lastest IMF main package. it means they didn't maintain the input engine interfaces like scim-pinyin, scim-chewing, scim-anthy, scim-canna, scim-tables, scim-skk....all of them.
That's bad. Since these broken packages aren't maintained by the main scim project but they are individuals, maybe the scim developers just ignored the breakage.
So any upstream bug report will be "abandoned".
Even if we can open and wait, openSUSE can't. Here's the situation:
According to its maintenance status (inactive package maintainers in M17N and upstream, the latest SR against one of them is from coolo about 12 month ago), broken status and popularity among the users, we have made a deal to get rid of it from DVD. And I removed provides tag from scim main package.
But, because of sub packages' broken status against Factory, I can't submit any SR against them.
It means we may have about 10 broken dependency packages installed in openSUSE 12.2. ( newer version of scim, and old versions of all the others. they can't work together.)
So possible solutions are:
1. Drop them completely.
Since I fixed all the packages related to zh_CN locale, and I don't know how many people use it in other locales. I can't make such decision. And another reason is because SLE_11_SP2 is still using it. (SLE_11_SP2 is a longer supported version. if I drop them, it'll cause many problems to both SuSE staff and SLE users. Dependencies in SLE_11_SP2 are not new enough to build other IMF like IBus/Fcitx/Mozc/Gcin.)
2. Fix them and remove the provides tags from them.
That's exactly I did.
Some maintainers said just let scim die. but if we can let it die, we have already done. scim-anthy, scim-chewing and others didn't see any new release since 2006, we're still maintaining it. Because there're no other solutions in some of openSUSE derivatives.
Now I have fixed: scim-pinyin, scim-unikey, scim-anthy, scim-hangul.
I can't fix others because it's out of my effort.
Some of the GTK functions and macros used in them are too old (GTK 2.12) and have no new alternatives.
It means we have to rewrite some lines of its codes. like GTK_Fileselection to GTK_Dialog, GTK_combo to GTK_combobox.
So if anyone have time and GTK coding experience, please offer some help.
Hmm, how other distros handle this update? Haven't they hit the same problems? I see both Ubuntu and Arch already updated to scim 1.4.13, but they can build scim-anthy as is. Judging from the compile errors, isn't it just a side-effect of using GTK3 in SCIM...? thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jun 11, 2012 at 10:26 PM, Takashi Iwai
At Sun, 10 Jun 2012 19:55:03 +0800, Marguerite Su wrote:
Hi, all,
I need some gtk coding help to fix scim related packages in M17N repository.
package status here: https://build.opensuse.org/project/monitor?blocked=0&building=0&dispatching=0&finished=0&project=M17N&scheduled=0&signing=0&succeeded=0
== Long version : ==
I updated scim main package to 1.4.13.
You may never heard of this project. It's an old Input Method Framework project. Upstream indeed didn't maintain it for a long time
They didn't claim it, but actually all Input Engine sub-packages can't be built against lastest IMF main package. it means they didn't maintain the input engine interfaces like scim-pinyin, scim-chewing, scim-anthy, scim-canna, scim-tables, scim-skk....all of them.
That's bad. Since these broken packages aren't maintained by the main scim project but they are individuals, maybe the scim developers just ignored the breakage.
yes...they ignored them. but only an IMF doesn't work...old and royal users still need engines to input.
So any upstream bug report will be "abandoned".
Even if we can open and wait, openSUSE can't. Here's the situation:
According to its maintenance status (inactive package maintainers in M17N and upstream, the latest SR against one of them is from coolo about 12 month ago), broken status and popularity among the users, we have made a deal to get rid of it from DVD. And I removed provides tag from scim main package.
But, because of sub packages' broken status against Factory, I can't submit any SR against them.
It means we may have about 10 broken dependency packages installed in openSUSE 12.2. ( newer version of scim, and old versions of all the others. they can't work together.)
So possible solutions are:
1. Drop them completely.
Since I fixed all the packages related to zh_CN locale, and I don't know how many people use it in other locales. I can't make such decision. And another reason is because SLE_11_SP2 is still using it. (SLE_11_SP2 is a longer supported version. if I drop them, it'll cause many problems to both SuSE staff and SLE users. Dependencies in SLE_11_SP2 are not new enough to build other IMF like IBus/Fcitx/Mozc/Gcin.)
2. Fix them and remove the provides tags from them.
That's exactly I did.
Some maintainers said just let scim die. but if we can let it die, we have already done. scim-anthy, scim-chewing and others didn't see any new release since 2006, we're still maintaining it. Because there're no other solutions in some of openSUSE derivatives.
Now I have fixed: scim-pinyin, scim-unikey, scim-anthy, scim-hangul.
I can't fix others because it's out of my effort.
Some of the GTK functions and macros used in them are too old (GTK 2.12) and have no new alternatives.
It means we have to rewrite some lines of its codes. like GTK_Fileselection to GTK_Dialog, GTK_combo to GTK_combobox.
So if anyone have time and GTK coding experience, please offer some help.
Hmm, how other distros handle this update? Haven't they hit the same problems? I see both Ubuntu and Arch already updated to scim 1.4.13, but they can build scim-anthy as is.
Judging from the compile errors, isn't it just a side-effect of using GTK3 in SCIM...?
That's the most interesting part: I see Fedora and Ubuntu have 1.4.13 and all other packages the same version as us. But they didn't patch anything. they just build fine. that part confuses me. I'm not that fresh to packaing and patching...those functions in them are from gtk 2.12 era, which are already dropped for a long time. why they can built it without any problem... I just update the source of scim, I didn't modify spec at all...and in sub packages, they introduce /usr/include/gtk-3.0/ even if you didn't specify gtk3-devel in spec file. I'm fixing scim-skk/scim-table with help from community now. The fix is easy for ones with a little gtk coding experience, it's just function replacement. The most hard part is scim-chewing.
thanks,
Takashi
Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Mon, 11 Jun 2012 23:44:59 +0800, Marguerite Su wrote:
Some of the GTK functions and macros used in them are too old (GTK 2.12) and have no new alternatives.
It means we have to rewrite some lines of its codes. like GTK_Fileselection to GTK_Dialog, GTK_combo to GTK_combobox.
So if anyone have time and GTK coding experience, please offer some help.
Hmm, how other distros handle this update? Haven't they hit the same problems? I see both Ubuntu and Arch already updated to scim 1.4.13, but they can build scim-anthy as is.
Judging from the compile errors, isn't it just a side-effect of using GTK3 in SCIM...?
That's the most interesting part:
I see Fedora and Ubuntu have 1.4.13 and all other packages the same version as us.
But they didn't patch anything. they just build fine. that part confuses me.
I'm not that fresh to packaing and patching...those functions in them are from gtk 2.12 era, which are already dropped for a long time. why they can built it without any problem...
I guess other distros don't use GTK3 for SCIM but keep using GTK2. The incompatible part is likely the change of widget components in file-selection or combo, i.e. somewhat internal in GTK widgets. So, maybe reverting to gtk2-devel in scim.rpm would have solved the breakage in scim-* subpackages automatically. But you've already fixed so many packages, and it's better to go foward at this point than taking back your previous works.
I just update the source of scim, I didn't modify spec at all...and in sub packages, they introduce /usr/include/gtk-3.0/ even if you didn't specify gtk3-devel in spec file.
I'm fixing scim-skk/scim-table with help from community now.
Great, thanks!
The fix is easy for ones with a little gtk coding experience, it's just function replacement.
The most hard part is scim-chewing.
Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jun 12, 2012 at 12:19 AM, Takashi Iwai
At Mon, 11 Jun 2012 23:44:59 +0800, Marguerite Su wrote:
Some of the GTK functions and macros used in them are too old (GTK 2.12) and have no new alternatives.
It means we have to rewrite some lines of its codes. like GTK_Fileselection to GTK_Dialog, GTK_combo to GTK_combobox.
So if anyone have time and GTK coding experience, please offer some help.
Hmm, how other distros handle this update? Haven't they hit the same problems? I see both Ubuntu and Arch already updated to scim 1.4.13, but they can build scim-anthy as is.
Judging from the compile errors, isn't it just a side-effect of using GTK3 in SCIM...?
That's the most interesting part:
I see Fedora and Ubuntu have 1.4.13 and all other packages the same version as us.
But they didn't patch anything. they just build fine. that part confuses me.
I'm not that fresh to packaing and patching...those functions in them are from gtk 2.12 era, which are already dropped for a long time. why they can built it without any problem...
I guess other distros don't use GTK3 for SCIM but keep using GTK2. The incompatible part is likely the change of widget components in file-selection or combo, i.e. somewhat internal in GTK widgets.
maybe... there're three kinds of errors: 1. gtktooltips ( most easy) 2. file-selection ( a little bit complicated but understandable) 3. combo to combobox what a mess...there're so many functions no longer available...I don't know how to deal with them, like: gtk_combo_set_value_in_list gtk_combo_set_case_sensitive gtk_combo_set_popdown_strings do you have any ideas? https://build.opensuse.org/package/show?package=scim-skk&project=home%3AMargueriteSu%3Abranches%3AM17N
So, maybe reverting to gtk2-devel in scim.rpm would have solved the breakage in scim-* subpackages automatically. But you've already fixed so many packages, and it's better to go foward at this point than taking back your previous works.
then maybe in the end we M17N team finish the work of porting scim related packages to gtk3...when I started, I didn't even know I was porting anything, I thought I was just fixing build errors...
I just update the source of scim, I didn't modify spec at all...and in sub packages, they introduce /usr/include/gtk-3.0/ even if you didn't specify gtk3-devel in spec file.
I'm fixing scim-skk/scim-table with help from community now.
Great, thanks!
The fix is easy for ones with a little gtk coding experience, it's just function replacement.
The most hard part is scim-chewing.
Takashi
Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Tue, 12 Jun 2012 00:28:40 +0800, Marguerite Su wrote:
On Tue, Jun 12, 2012 at 12:19 AM, Takashi Iwai
wrote: At Mon, 11 Jun 2012 23:44:59 +0800, Marguerite Su wrote:
Some of the GTK functions and macros used in them are too old (GTK 2.12) and have no new alternatives.
It means we have to rewrite some lines of its codes. like GTK_Fileselection to GTK_Dialog, GTK_combo to GTK_combobox.
So if anyone have time and GTK coding experience, please offer some help.
Hmm, how other distros handle this update? Haven't they hit the same problems? I see both Ubuntu and Arch already updated to scim 1.4.13, but they can build scim-anthy as is.
Judging from the compile errors, isn't it just a side-effect of using GTK3 in SCIM...?
That's the most interesting part:
I see Fedora and Ubuntu have 1.4.13 and all other packages the same version as us.
But they didn't patch anything. they just build fine. that part confuses me.
I'm not that fresh to packaing and patching...those functions in them are from gtk 2.12 era, which are already dropped for a long time. why they can built it without any problem...
I guess other distros don't use GTK3 for SCIM but keep using GTK2. The incompatible part is likely the change of widget components in file-selection or combo, i.e. somewhat internal in GTK widgets.
maybe...
there're three kinds of errors:
1. gtktooltips ( most easy) 2. file-selection ( a little bit complicated but understandable) 3. combo to combobox
what a mess...there're so many functions no longer available...I don't know how to deal with them, like:
gtk_combo_set_value_in_list gtk_combo_set_case_sensitive gtk_combo_set_popdown_strings
do you have any ideas?
That's not trivial, unfortunately... Looking at more on scim-chewing code, especially scim_color_button stuff is fairly hard to port to GTK3 as it's using lots of deprecated (and actaully dropped) functions. Definitely it isn't worth to waste time for doing that.
So, maybe reverting to gtk2-devel in scim.rpm would have solved the breakage in scim-* subpackages automatically. But you've already fixed so many packages, and it's better to go foward at this point than taking back your previous works.
then maybe in the end we M17N team finish the work of porting scim related packages to gtk3...when I started, I didn't even know I was porting anything, I thought I was just fixing build errors...
Yeah, that was the fact. And, looking at how the GTK3 porting can be intrusive, desprite of my previous comment, I'd suggest to go back to GTK2 in scim packaging. The necessary change is simple, just pass --with-gtk-version=2 to configure script in scim. SCIM is an old stuff, as you already mentioned. In such a case, there is no big reason to take a huge risk of regressions by untested updates. I prepared scim updates now with GTK2 in OBS home:tiwai:branches:M17N repos. All builds look OK, so far. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jun 12, 2012 at 10:55 PM, Takashi Iwai
At Tue, 12 Jun 2012 00:28:40 +0800, Marguerite Su wrote:
On Tue, Jun 12, 2012 at 12:19 AM, Takashi Iwai
wrote: At Mon, 11 Jun 2012 23:44:59 +0800, Marguerite Su wrote:
Some of the GTK functions and macros used in them are too old (GTK 2.12) and have no new alternatives.
It means we have to rewrite some lines of its codes. like GTK_Fileselection to GTK_Dialog, GTK_combo to GTK_combobox.
So if anyone have time and GTK coding experience, please offer some help.
Hmm, how other distros handle this update? Haven't they hit the same problems? I see both Ubuntu and Arch already updated to scim 1.4.13, but they can build scim-anthy as is.
Judging from the compile errors, isn't it just a side-effect of using GTK3 in SCIM...?
That's the most interesting part:
I see Fedora and Ubuntu have 1.4.13 and all other packages the same version as us.
But they didn't patch anything. they just build fine. that part confuses me.
I'm not that fresh to packaing and patching...those functions in them are from gtk 2.12 era, which are already dropped for a long time. why they can built it without any problem...
I guess other distros don't use GTK3 for SCIM but keep using GTK2. The incompatible part is likely the change of widget components in file-selection or combo, i.e. somewhat internal in GTK widgets.
maybe...
there're three kinds of errors:
1. gtktooltips ( most easy) 2. file-selection ( a little bit complicated but understandable) 3. combo to combobox
what a mess...there're so many functions no longer available...I don't know how to deal with them, like:
gtk_combo_set_value_in_list gtk_combo_set_case_sensitive gtk_combo_set_popdown_strings
do you have any ideas?
That's not trivial, unfortunately...
Looking at more on scim-chewing code, especially scim_color_button stuff is fairly hard to port to GTK3 as it's using lots of deprecated (and actaully dropped) functions. Definitely it isn't worth to waste time for doing that.
Yes...I tried to fix GtkObjectClass errors, then It comes a lot of other errors. Swyear asked taiwan developers to fix it. maybe I can wait for a while to hear his results.
So, maybe reverting to gtk2-devel in scim.rpm would have solved the breakage in scim-* subpackages automatically. But you've already fixed so many packages, and it's better to go foward at this point than taking back your previous works.
then maybe in the end we M17N team finish the work of porting scim related packages to gtk3...when I started, I didn't even know I was porting anything, I thought I was just fixing build errors...
Yeah, that was the fact. And, looking at how the GTK3 porting can be intrusive, desprite of my previous comment, I'd suggest to go back to GTK2 in scim packaging. The necessary change is simple, just pass --with-gtk-version=2 to configure script in scim.
SCIM is an old stuff, as you already mentioned. In such a case, there is no big reason to take a huge risk of regressions by untested updates.
I prepared scim updates now with GTK2 in OBS home:tiwai:branches:M17N repos. All builds look OK, so far.
I saw that on OBS index when you branched. maybe we can take your branch as a failsafe and see what my branch can do? now I have scim-anthy, scim-pinyin, scim-hangul, scim-skk, scim-unikey, scim-canna, novell-pinyin fixed(or ported)...all the things left are scim-uim and scim-chewing. maybe if community and I work a little harder...dream will come true...LOL
thanks,
Takashi
Greetings, Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Tue, 12 Jun 2012 23:06:43 +0800, Marguerite Su wrote:
On Tue, Jun 12, 2012 at 10:55 PM, Takashi Iwai
wrote: At Tue, 12 Jun 2012 00:28:40 +0800, Marguerite Su wrote:
On Tue, Jun 12, 2012 at 12:19 AM, Takashi Iwai
wrote: At Mon, 11 Jun 2012 23:44:59 +0800, Marguerite Su wrote:
> Some of the GTK functions and macros used in them are too old (GTK > 2.12) and have no new alternatives. > > It means we have to rewrite some lines of its codes. like > GTK_Fileselection to GTK_Dialog, GTK_combo to GTK_combobox. > > So if anyone have time and GTK coding experience, please offer some help.
Hmm, how other distros handle this update? Haven't they hit the same problems? I see both Ubuntu and Arch already updated to scim 1.4.13, but they can build scim-anthy as is.
Judging from the compile errors, isn't it just a side-effect of using GTK3 in SCIM...?
That's the most interesting part:
I see Fedora and Ubuntu have 1.4.13 and all other packages the same version as us.
But they didn't patch anything. they just build fine. that part confuses me.
I'm not that fresh to packaing and patching...those functions in them are from gtk 2.12 era, which are already dropped for a long time. why they can built it without any problem...
I guess other distros don't use GTK3 for SCIM but keep using GTK2. The incompatible part is likely the change of widget components in file-selection or combo, i.e. somewhat internal in GTK widgets.
maybe...
there're three kinds of errors:
1. gtktooltips ( most easy) 2. file-selection ( a little bit complicated but understandable) 3. combo to combobox
what a mess...there're so many functions no longer available...I don't know how to deal with them, like:
gtk_combo_set_value_in_list gtk_combo_set_case_sensitive gtk_combo_set_popdown_strings
do you have any ideas?
That's not trivial, unfortunately...
Looking at more on scim-chewing code, especially scim_color_button stuff is fairly hard to port to GTK3 as it's using lots of deprecated (and actaully dropped) functions. Definitely it isn't worth to waste time for doing that.
Yes...I tried to fix GtkObjectClass errors, then It comes a lot of other errors.
GtkObjectClass is a simple thing. It can be changed mostly to GtkWidget. And expose event can be changed to draw. But the actual rendering part, especially the implementation of the own color-selection button is harder to port. You'd need to convert gdk thingies there to cairo helpers, or equivalent ones.
Swyear asked taiwan developers to fix it. maybe I can wait for a while to hear his results.
So, maybe reverting to gtk2-devel in scim.rpm would have solved the breakage in scim-* subpackages automatically. But you've already fixed so many packages, and it's better to go foward at this point than taking back your previous works.
then maybe in the end we M17N team finish the work of porting scim related packages to gtk3...when I started, I didn't even know I was porting anything, I thought I was just fixing build errors...
Yeah, that was the fact. And, looking at how the GTK3 porting can be intrusive, desprite of my previous comment, I'd suggest to go back to GTK2 in scim packaging. The necessary change is simple, just pass --with-gtk-version=2 to configure script in scim.
SCIM is an old stuff, as you already mentioned. In such a case, there is no big reason to take a huge risk of regressions by untested updates.
I prepared scim updates now with GTK2 in OBS home:tiwai:branches:M17N repos. All builds look OK, so far.
I saw that on OBS index when you branched. maybe we can take your branch as a failsafe and see what my branch can do?
now I have scim-anthy, scim-pinyin, scim-hangul, scim-skk, scim-unikey, scim-canna, novell-pinyin fixed(or ported)...all the things left are scim-uim and scim-chewing. maybe if community and I work a little harder...dream will come true...LOL
Of course, works to fix these are really appreciated, but honestly speaking, I really don't think it's woth to spend more time on that. Better to improve fcitx, instead :) GTK2 won't be dropped so soon, so we can keep using it. (Note that --with-gtk-version=2 option doesn't stop building GTK3 IM module of SCIM. It's just that scim itself (and library) is linked with gtk2 instead of the default gtk3.) thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jun 12, 2012 at 11:17 PM, Takashi Iwai
At Tue, 12 Jun 2012 23:06:43 +0800, Marguerite Su wrote:
On Tue, Jun 12, 2012 at 10:55 PM, Takashi Iwai
wrote: At Tue, 12 Jun 2012 00:28:40 +0800, Marguerite Su wrote:
On Tue, Jun 12, 2012 at 12:19 AM, Takashi Iwai
wrote: At Mon, 11 Jun 2012 23:44:59 +0800, Marguerite Su wrote:
>> Some of the GTK functions and macros used in them are too old (GTK >> 2.12) and have no new alternatives. >> >> It means we have to rewrite some lines of its codes. like >> GTK_Fileselection to GTK_Dialog, GTK_combo to GTK_combobox. >> >> So if anyone have time and GTK coding experience, please offer some help. > > Hmm, how other distros handle this update? Haven't they hit the same > problems? I see both Ubuntu and Arch already updated to scim 1.4.13, > but they can build scim-anthy as is. > > Judging from the compile errors, isn't it just a side-effect of using > GTK3 in SCIM...?
That's the most interesting part:
I see Fedora and Ubuntu have 1.4.13 and all other packages the same version as us.
But they didn't patch anything. they just build fine. that part confuses me.
I'm not that fresh to packaing and patching...those functions in them are from gtk 2.12 era, which are already dropped for a long time. why they can built it without any problem...
I guess other distros don't use GTK3 for SCIM but keep using GTK2. The incompatible part is likely the change of widget components in file-selection or combo, i.e. somewhat internal in GTK widgets.
maybe...
there're three kinds of errors:
1. gtktooltips ( most easy) 2. file-selection ( a little bit complicated but understandable) 3. combo to combobox
what a mess...there're so many functions no longer available...I don't know how to deal with them, like:
gtk_combo_set_value_in_list gtk_combo_set_case_sensitive gtk_combo_set_popdown_strings
do you have any ideas?
That's not trivial, unfortunately...
Looking at more on scim-chewing code, especially scim_color_button stuff is fairly hard to port to GTK3 as it's using lots of deprecated (and actaully dropped) functions. Definitely it isn't worth to waste time for doing that.
Yes...I tried to fix GtkObjectClass errors, then It comes a lot of other errors.
GtkObjectClass is a simple thing. It can be changed mostly to GtkWidget. And expose event can be changed to draw. But the actual rendering part, especially the implementation of the own color-selection button is harder to port. You'd need to convert gdk thingies there to cairo helpers, or equivalent ones.
Swyear asked taiwan developers to fix it. maybe I can wait for a while to hear his results.
So, maybe reverting to gtk2-devel in scim.rpm would have solved the breakage in scim-* subpackages automatically. But you've already fixed so many packages, and it's better to go foward at this point than taking back your previous works.
then maybe in the end we M17N team finish the work of porting scim related packages to gtk3...when I started, I didn't even know I was porting anything, I thought I was just fixing build errors...
Yeah, that was the fact. And, looking at how the GTK3 porting can be intrusive, desprite of my previous comment, I'd suggest to go back to GTK2 in scim packaging. The necessary change is simple, just pass --with-gtk-version=2 to configure script in scim.
SCIM is an old stuff, as you already mentioned. In such a case, there is no big reason to take a huge risk of regressions by untested updates.
I prepared scim updates now with GTK2 in OBS home:tiwai:branches:M17N repos. All builds look OK, so far.
I saw that on OBS index when you branched. maybe we can take your branch as a failsafe and see what my branch can do?
now I have scim-anthy, scim-pinyin, scim-hangul, scim-skk, scim-unikey, scim-canna, novell-pinyin fixed(or ported)...all the things left are scim-uim and scim-chewing. maybe if community and I work a little harder...dream will come true...LOL
Of course, works to fix these are really appreciated, but honestly speaking, I really don't think it's woth to spend more time on that. Better to improve fcitx, instead :)
Haha, to talk about fcitx, fcitx-anthy is nearly ready. (weng stayed up for about 3 to 4 nights and get it done) it's now in an inside testing state. maybe later this week I'll package it to M17N:Devel
GTK2 won't be dropped so soon, so we can keep using it. (Note that --with-gtk-version=2 option doesn't stop building GTK3 IM module of SCIM. It's just that scim itself (and library) is linked with gtk2 instead of the default gtk3.)
Yes...if you told me a little earlier...it'll save me a lot time...but...now I even fixed novel-pinyin...only three to four left...it's really hard to give up... Actually except for scim-chewing, other fixes are just function migration like gtktooltips..not rewrite or something, so it won't affect stability too much...
thanks,
Takashi
Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Tue, 12 Jun 2012 23:56:10 +0800, Marguerite Su wrote:
On Tue, Jun 12, 2012 at 11:17 PM, Takashi Iwai
wrote: At Tue, 12 Jun 2012 23:06:43 +0800, Marguerite Su wrote:
On Tue, Jun 12, 2012 at 10:55 PM, Takashi Iwai
wrote: At Tue, 12 Jun 2012 00:28:40 +0800, Marguerite Su wrote:
On Tue, Jun 12, 2012 at 12:19 AM, Takashi Iwai
wrote: At Mon, 11 Jun 2012 23:44:59 +0800, Marguerite Su wrote: > > >> Some of the GTK functions and macros used in them are too old (GTK > >> 2.12) and have no new alternatives. > >> > >> It means we have to rewrite some lines of its codes. like > >> GTK_Fileselection to GTK_Dialog, GTK_combo to GTK_combobox. > >> > >> So if anyone have time and GTK coding experience, please offer some help. > > > > Hmm, how other distros handle this update? Haven't they hit the same > > problems? I see both Ubuntu and Arch already updated to scim 1.4.13, > > but they can build scim-anthy as is. > > > > Judging from the compile errors, isn't it just a side-effect of using > > GTK3 in SCIM...? > > That's the most interesting part: > > I see Fedora and Ubuntu have 1.4.13 and all other packages the same > version as us. > > But they didn't patch anything. they just build fine. that part confuses me. > > I'm not that fresh to packaing and patching...those functions in them > are from gtk 2.12 era, which are already dropped for a long time. why > they can built it without any problem...
I guess other distros don't use GTK3 for SCIM but keep using GTK2. The incompatible part is likely the change of widget components in file-selection or combo, i.e. somewhat internal in GTK widgets.
maybe...
there're three kinds of errors:
1. gtktooltips ( most easy) 2. file-selection ( a little bit complicated but understandable) 3. combo to combobox
what a mess...there're so many functions no longer available...I don't know how to deal with them, like:
gtk_combo_set_value_in_list gtk_combo_set_case_sensitive gtk_combo_set_popdown_strings
do you have any ideas?
That's not trivial, unfortunately...
Looking at more on scim-chewing code, especially scim_color_button stuff is fairly hard to port to GTK3 as it's using lots of deprecated (and actaully dropped) functions. Definitely it isn't worth to waste time for doing that.
Yes...I tried to fix GtkObjectClass errors, then It comes a lot of other errors.
GtkObjectClass is a simple thing. It can be changed mostly to GtkWidget. And expose event can be changed to draw. But the actual rendering part, especially the implementation of the own color-selection button is harder to port. You'd need to convert gdk thingies there to cairo helpers, or equivalent ones.
Swyear asked taiwan developers to fix it. maybe I can wait for a while to hear his results.
So, maybe reverting to gtk2-devel in scim.rpm would have solved the breakage in scim-* subpackages automatically. But you've already fixed so many packages, and it's better to go foward at this point than taking back your previous works.
then maybe in the end we M17N team finish the work of porting scim related packages to gtk3...when I started, I didn't even know I was porting anything, I thought I was just fixing build errors...
Yeah, that was the fact. And, looking at how the GTK3 porting can be intrusive, desprite of my previous comment, I'd suggest to go back to GTK2 in scim packaging. The necessary change is simple, just pass --with-gtk-version=2 to configure script in scim.
SCIM is an old stuff, as you already mentioned. In such a case, there is no big reason to take a huge risk of regressions by untested updates.
I prepared scim updates now with GTK2 in OBS home:tiwai:branches:M17N repos. All builds look OK, so far.
I saw that on OBS index when you branched. maybe we can take your branch as a failsafe and see what my branch can do?
now I have scim-anthy, scim-pinyin, scim-hangul, scim-skk, scim-unikey, scim-canna, novell-pinyin fixed(or ported)...all the things left are scim-uim and scim-chewing. maybe if community and I work a little harder...dream will come true...LOL
Of course, works to fix these are really appreciated, but honestly speaking, I really don't think it's woth to spend more time on that. Better to improve fcitx, instead :)
Haha, to talk about fcitx, fcitx-anthy is nearly ready. (weng stayed up for about 3 to 4 nights and get it done)
it's now in an inside testing state.
maybe later this week I'll package it to M17N:Devel
OK.
GTK2 won't be dropped so soon, so we can keep using it. (Note that --with-gtk-version=2 option doesn't stop building GTK3 IM module of SCIM. It's just that scim itself (and library) is linked with gtk2 instead of the default gtk3.)
Yes...if you told me a little earlier...it'll save me a lot time...
Oh, if you told me the problme a bit earlier... ;)
but...now I even fixed novel-pinyin...only three to four left...it's really hard to give up...
Well, my concern is about the stability. I guess you've just fixed builds but not tested the actual system so much. Such a program is difficult to test actually if you don't know of the exotic operation. If the changes are only in SCIM, you can test one of the component you are familiar with (i.e. the Chinese IM) to see whether any regression happens. But for all these components? It's a lot of QA works. So, I guess that a safer way at this moment is a smaller change.
Actually except for scim-chewing, other fixes are just function migration like gtktooltips..not rewrite or something, so it won't affect stability too much...
Yes, I looked through your patches (at least the ones in M17N), and these look OK. The patches work even with the recent GTK2, except for the version in 11.4. So, I keep these in the packages in my branched ones. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Marguerite, At Tue, 12 Jun 2012 18:02:27 +0200, Takashi Iwai wrote:
Well, my concern is about the stability. I guess you've just fixed builds but not tested the actual system so much. Such a program is difficult to test actually if you don't know of the exotic operation.
If the changes are only in SCIM, you can test one of the component you are familiar with (i.e. the Chinese IM) to see whether any regression happens. But for all these components? It's a lot of QA works.
So, I guess that a safer way at this moment is a smaller change.
Now I decided to take back to GTK2 and disable porting patches _temporarily_ on M17N repo. I hope you won't feel bad with that. Your changes are still found in the spec file but protected via %{scim_gtk3} flag. After all, we need some stably working stuff at this stage. I branched all scim-related packages and enabled GTK3 things in M17N:Devel repo. So, if you have pending works, please continue on there. I also removed gtk2-devel buildrequires to make sure that you don't mix up gtk2 and gtk3 in IM-engine packages. Let's see what happens in M17N:Devel builds. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Jun 13, 2012 at 8:28 PM, Takashi Iwai
Marguerite,
At Tue, 12 Jun 2012 18:02:27 +0200, Takashi Iwai wrote:
Well, my concern is about the stability. I guess you've just fixed builds but not tested the actual system so much. Such a program is difficult to test actually if you don't know of the exotic operation.
If the changes are only in SCIM, you can test one of the component you are familiar with (i.e. the Chinese IM) to see whether any regression happens. But for all these components? It's a lot of QA works.
So, I guess that a safer way at this moment is a smaller change.
Now I decided to take back to GTK2 and disable porting patches _temporarily_ on M17N repo. I hope you won't feel bad with that. Your changes are still found in the spec file but protected via %{scim_gtk3} flag. After all, we need some stably working stuff at this stage.
Of course not. I saw your SRs yesterday.
I branched all scim-related packages and enabled GTK3 things in M17N:Devel repo. So, if you have pending works, please continue on there.
I also removed gtk2-devel buildrequires to make sure that you don't mix up gtk2 and gtk3 in IM-engine packages. Let's see what happens in M17N:Devel builds.
Ok. it frees my hand a little bit actually...so I don't need to be hurry for 12.2. Thanks.
thanks,
Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Marguerite Su wrote
I saw that on OBS index when you branched. maybe we can take your branch as a failsafe and see what my branch can do?
now I have scim-anthy, scim-pinyin, scim-hangul, scim-skk, scim-unikey, scim-canna, novell-pinyin fixed(or ported)...all the things left are scim-uim and scim-chewing.
Hi Marguerite, I am maintaining the SCIM currently. I'm sorry that we didn't update scim-* as well as the scim itself. We don't want to ignore the breakage, we just have no time to update all of them. I am going to start to port scim-anthy to gtk3 and I find that you have done it. I deeply appreciate if you can share the patches, so that I can commit them to the SCIM repository and work on scim-uim and scim-chewing instead. Thanks, Tz-Huan -- View this message in context: http://opensuse.14.n6.nabble.com/M17N-scim-gtk-help-needed-tp4967112p4969003... Sent from the opensuse-factory mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jun 29, 2012 at 6:07 PM, tzhuan
Marguerite Su wrote
I saw that on OBS index when you branched. maybe we can take your branch as a failsafe and see what my branch can do?
now I have scim-anthy, scim-pinyin, scim-hangul, scim-skk, scim-unikey, scim-canna, novell-pinyin fixed(or ported)...all the things left are scim-uim and scim-chewing.
Hi Marguerite,
I am maintaining the SCIM currently. I'm sorry that we didn't update scim-* as well as the scim itself. We don't want to ignore the breakage, we just have no time to update all of them. I am going to start to port scim-anthy to gtk3 and I find that you have done it. I deeply appreciate if you can share the patches, so that I can commit them to the SCIM repository and work on scim-uim and scim-chewing instead.
Thanks, Tz-Huan
-- View this message in context: http://opensuse.14.n6.nabble.com/M17N-scim-gtk-help-needed-tp4967112p4969003... Sent from the opensuse-factory mailing list archive at Nabble.com. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Huan.T.Z, Just go to https://build.opensuse.org/project/packages?project=M17N, and click scim-* package names, then go to "Source". You can download all the patches without login. I didn't keep my patches local either. And you need to test/review them, I just make them build, but since I know nothing about GTK+, my patches may be ridiculous. the gtk combo to combobox, or gtk optionmenu to combobox is a mystery to me. (my patch can build, but may loose function due to I don't know the original code want to do). You need to use with caution. By the way scim-anthy now is still using GTK2, seems BinLi's first patch force it. you have to that patch if you want to do a real port. then it'll generate similar errors as scim-chewing. scim-pinyin novell-pinyin are just good. but scim-anthy, scim-skk, scim-chewing are the ones need a lot of expertise. By the way, can you help fix skim-scim-anthy/chewing/skk in a few days? I don't where their problems are, they can't build for our Factory. (seems to be autotools. they can't build a usable .so library) Greetings, Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jun 29, 2012 at 6:30 PM, Marguerite Su wrote:
Hi, Huan.T.Z,
Just go to https://build.opensuse.org/project/packages?project=M17N, and click scim-* package names, then go to "Source".
You can download all the patches without login. I didn't keep my patches local either.
And you need to test/review them, I just make them build, but since I know nothing about GTK+, my patches may be ridiculous. the gtk combo to combobox, or gtk optionmenu to combobox is a mystery to me. (my patch can build, but may loose function due to I don't know the original code want to do).
You need to use with caution.
By the way scim-anthy now is still using GTK2, seems BinLi's first patch force it. you have to that patch if you want to do a real port. then it'll generate similar errors as scim-chewing.
scim-pinyin novell-pinyin are just good. but scim-anthy, scim-skk, scim-chewing are the ones need a lot of expertise.
By the way, can you help fix skim-scim-anthy/chewing/skk in a few days?
I don't where their problems are, they can't build for our Factory. (seems to be autotools. they can't build a usable .so library)
Hi Marguerite, Thank you very much for the patches. By the way, the GtkCombo and GtkOptionMenu are also nightmare to me, and I am also busy on Debian freeze. I'll try it but I cannot promise that I can fix skim-scim-anthy/chewing/skk in time. Thanks, Tz-Huan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jun 29, 2012 at 6:30 PM, Marguerite Su wrote:
By the way, can you help fix skim-scim-anthy/chewing/skk in a few days?
I don't where their problems are, they can't build for our Factory. (seems to be autotools. they can't build a usable .so library)
I have fixed the scim-chewing. You can find the patches here: https://github.com/tzhuan/scim-chewing For skim-scim-anthy, I probably won't touch it because I have no idea about skim and Qt at this moment. I'll start to work on anthy and skk, hope that I can fix them soon. Thanks, Tz-Huan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Jul 1, 2012 at 3:55 AM, Tz-Huan Huang
On Fri, Jun 29, 2012 at 6:30 PM, Marguerite Su wrote:
By the way, can you help fix skim-scim-anthy/chewing/skk in a few days?
I don't where their problems are, they can't build for our Factory. (seems to be autotools. they can't build a usable .so library)
I have fixed the scim-chewing. You can find the patches here: https://github.com/tzhuan/scim-chewing
scim-anthy (not skim-scim-anthy, sorry) and scim-skk are also fixed. https://github.com/tzhuan/scim-anthy https://github.com/tzhuan/scim-skk FYI. Tz-Huan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Marguerite Su
-
Takashi Iwai
-
Tz-Huan Huang
-
tzhuan