Hi, all.
This thread is about engine property filtering rather than engine list
filtering.
Though we discussed engine list filtering and many off topic issues, anyway.
Wanna know why engine property filtering can cause serious regression
on CJK inputting experience?
Please check my videos recored
On Fri, Nov 23, 2012 at 7:27 PM, Allan Day wrote:
> Florian Müllner wrote:
> ...
The Tweak Tool shouldn't have anything to do with extensions. They are
something that you install and run as a part of the system, not
something to be "tweaked" via settings.
>>
>> While I agree with y
The idea of using the web page as management was an idea that Owen had, and
in some ways it was a logical progression of the "addons.mozilla.org"
experience: you get extensions from the web site, so why not
enable/disable/configure/uninstall them from there too?
It's a good idea, but a myriad of t
Florian Müllner wrote:
...
>>> The Tweak Tool shouldn't have anything to do with extensions. They are
>>> something that you install and run as a part of the system, not
>>> something to be "tweaked" via settings.
>
> While I agree with you that gnome-tweak-tool (and package managers
> (*)) are no
On Fri, Nov 23, 2012 at 5:59 PM, Matthias Clasen
wrote:
> On Fri, Nov 23, 2012 at 4:04 AM, Allan Day wrote:
>> A separate user session would be the best user experience, IMO.
>
> If you think so, we'll have to discuss the technicalities of making that work.
Thinking a bit about this, we can prob
On Fri, Nov 23, 2012 at 4:04 AM, Allan Day wrote:
> Matthias Clasen wrote:
>>> to be fair, I'd envision this as a completely separate session that
>>> you need to install and select, similar to what Ubuntu does —
>>> especially if we want to call it "GNOME Classic".
>
> Agreed.
>
>> I don't think
Hi,
Last time we rejected fcitx and an universal protocol because we have
limited resources, then this time we rejected some of input methods
based on IBus framework because we think they're of low quality.
So the road is narrower than before. Personally I think it's not to
integrate a IMF to des
Hi,
>I would think GNOME as OSS should treat everything open without
> discriminating any input method platform or input method engines. >Every
> person has different value on quality, which creating a white/blacklist to
> separate engines based on some criteria defined by a >board is appropriate.
s/appropriate/inappropriate/
On 24 November 2012 00:04, Caius Chance wrote:
> Hi all,
>
> I would think GNOME as OSS should treat everything open without
> discriminating any input method platform or input method engines. Every
> person has different value on quality, which creating a white/bla
Hi all,
I would think GNOME as OSS should treat everything open without
discriminating any input method platform or input method engines. Every
person has different value on quality, which creating a white/blacklist to
separate engines based on some criteria defined by a board is appropriate.
Inp
On Fri, Nov 23, 2012 at 5:09 PM, Debarshi Ray wrote:
> > So you want to keep of track all useful engines? What's good for that?
>
> Yes.
>
> The good thing is that users, who are not familiar with all the
> politics of free software input method frameworks and engines, get to
> choose from a list
I should say fcitx with kimpanel still works at gnome 3.6 , but it's
running slower than that in gnome 3.4, and even slower than that in gnome
3.2, which means a same extension is running slower and slower with
gnome-shell upgrades.
As ibus experience still sucks at gnome, ibus or gnome, which o
To make my point clear.
Once we have a fixed framework of inputting.
Installing/Uninstalling a new engine should be similar to
installing/uninstalling a new app.
There is no black magic here.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.o
On decent engines are available and easy to install. I can give a example.
Both ibus-table's quick and Mac OS X's quick has different experience
with that of Windows.
Some people don't the different experience, what can they do?
1. On Linux, you can either:
Hack /usr/share/ibus-table/engine/table.p
On Fri, Nov 23, 2012 at 4:17 AM, Debarshi Ray wrote:
> So why not fix and improve the current engines?
Sure we should. But that's unrelated. What I asking for now is not to
cause regression to existing user experience.
> But then you just said that the current engines are all inferior to
> the o
On Friday, November 23, 2012 06:01 PM, Pierre-Yves Luyten wrote:
Maybe should first step be listing different "functional principles",
for example
* Input from sound (pinyin input methods)
* Input from shape (canjie)
* Input from shape (wubi)
There will be a significant list, but not infinite.
>> Input methods and keyboard layouts are similar. They should just
>> work. We are working hard to achieve that. We are not there yet. You
>> are welcome to help out by fixing the engines and proposing good
>> defaults.
>
> No, they aren't.
> You shouldn't make such claim before you can type a pa
> No, you are making things even worse.
> [...]
> (They are
> likely to try so because current engines are virtually all inferior to
> those found in closed-source system)
> BTW, on Redmond OS or Mac OS X, if you Google/Baidu for input methods,
> most of them would just work.
So why not fix and im
turing complete, sorry
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
On Fri, Nov 23, 2012 at 4:01 AM, Pierre-Yves Luyten wrot
> Hi,
>
> Maybe should first step be listing different "functional principles",
> for example
>
> * Input from sound (pinyin input methods)
> * Input from shape (canjie)
> * Input from shape (wubi)
>
> There will be a significant list, but n
On Fri, Nov 23, 2012 at 3:09 AM, Debarshi Ray wrote:
> The good thing is that users, who are not familiar with all the
> politics of free software input method frameworks and engines, get to
> choose from a list of good quality engines. They do not have to go
> searching all over the Internet to f
> So you want to keep of track all useful engines? What's good for that?
Yes.
The good thing is that users, who are not familiar with all the
politics of free software input method frameworks and engines, get to
choose from a list of good quality engines. They do not have to go
searching all over
Matthias Clasen wrote:
>> to be fair, I'd envision this as a completely separate session that
>> you need to install and select, similar to what Ubuntu does —
>> especially if we want to call it "GNOME Classic".
Agreed.
> I don't think a separate session will work very well for this - for
> one
On Fri, 2012-11-23 at 01:50 -0600, Ma Xiaojun wrote:
> I find that you are arrogant and show no respect to other people's work.
> You can pick a default list according to your standard.
> But users and developers have freedom to use and develop 'third-party'
> one. As I said white list is unprecede
On Fri, Nov 23, 2012 at 1:59 AM, Mathieu Bridon
wrote:
> You're once again assuming you know what I think, instead of just trying to
> have a productive conversation by answering questions, which were (as I
> already clarified) purely meant to learn more about what you know that I
> don't.
Partic
On Friday, November 23, 2012 01:42 PM, Ma Xiaojun wrote:
On Thu, Nov 22, 2012 at 10:24 PM, Mathieu Bridon
wrote:
What I actually find very rude of you is that you seem to somehow interpret
my messages as having some kind of background intent.
I was asking a question. A real question, because I
26 matches
Mail list logo
