Re: Concerning Keyboard Status Menu
On Friday, November 23, 2012 01:42 PM, Ma Xiaojun wrote: On Thu, Nov 22, 2012 at 10:24 PM, Mathieu Bridon boche...@fedoraproject.org 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 wanted you to inform me on how things are in Mainland China. But you assumed I was just trying to undermine your argument and assuming that I was already right, which absolutely wasn't the case. Can we not just have a honest conversation where both parties talk seriously and inform each other, instead of interpreting what we think others are saying, and calling them arrogant? [... snip ...] I do feel that you try hard to defend GNOME's current implementation rather than thinking about it critically. 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. That's fine. But I decided to not to waste both of our time to explain things. So even when I have actually asked you (twice here and more on IRC) to explain, doing so would be wasting both of our time and you won't do it? I guess I'll just stop caring about whatever you're rambling on then. Fortunately for everybody, there are others who are happy to explain how their language work, and what users need and expect when inputting it. These people are being extremely helpful and patient. They provide a valuable service to IBus, GNOME, and the wider community of users and developers. With your last few emails to this list, you don't. -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
On Fri, Nov 23, 2012 at 1:59 AM, Mathieu Bridon boche...@fedoraproject.org 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. Participating in this discussion already ruined one of my day. Yes, I get impatient now. So, please try do the exercise first, I'm sorry. So even when I have actually asked you (twice here and more on IRC) to explain, doing so would be wasting both of our time and you won't do it? I guess I'll just stop caring about whatever you're rambling on then. Yes I'm rambling and I'm rude. But I do believe that I have stronger feeling than you guys that probably never inputted a single Chinese paragraph. Fortunately for everybody, there are others who are happy to explain how their language work, and what users need and expect when inputting it. These people are being extremely helpful and patient. They provide a valuable service to IBus, GNOME, and the wider community of users and developers. With your last few emails to this list, you don't. That's exactly why I lose patient. You guys implicitly assume that the situation of Chinese is similar to other languages. It isn't. I feel that will be more fair if you can do my above mentioned exercise first. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
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 unprecedented sh*t in the history of CJK inputing. And this is the end of the thread. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fallback mode is going away - what now ?
Matthias Clasen matthias.cla...@gmail.com 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 thing, setting this up will require a number of settings to be tweaked (e.g. the one for the minimize button), and alternative sessions don't have the right infrastructure for that. A separate user session would be the best user experience, IMO. The session chooser on the login screen is not the best designed part of the login experience either. That's a non-argument. We can improve it. The Tweak Tool is *completely* the wrong place for this. In what way is completely changing the shell a tweak? How does it make sense to be able to completely change the experience using a setting that is included in a non-core application, and which could later be removed? What kind of experience will you get when the shell transitions to classic mode right in front of the user's eyes? 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. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
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 the Internet to figure out what is what, and what is more broken or less broken, and so on. If some of the engines are still lacking in features, you are welcome to improve them. Yes, that won't happen in a single day. But if you do the heavy lifting then you actually improve things instead of constantly working around things that are broken. There is a phrase called draining the swap. That is what we are trying to do here. If you think that an engine that is listed should be replaced by another because it is better than the one that is listed, then you are welcome to request that. You can even submit a patch to make that switch. Why don't GNOME maintain a whitelist for applications either? Because unlike typing and inputing with a mouse or keyboard, people do not perceive applications to be part of the OS or the desktop environment (or whatever it is that you want to call it). Do you have to choose from a dozen different drivers just to get your keyboard or mouse to work? 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. Or you can wait for someone else to do it for you. Cheers, Debarshi -- There are two hard problems in computer science: cache invalidation, naming things and off-by-one errors. pgp05XaNBfto0.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
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 improve the current engines? Many engines just working well in 1.4 environment. It's IBus 1.4.99's API change and GNOMEism white list that break them. I feel that you get cause and effect wrong. But then you just said that the current engines are all inferior to the ones found in Windows and Mac OSX. No, input methods have flavors. Redmond OS users, OS X users don't have a consensus of which input method is best. But who cares? They are more happy in respect to Chinese inputting. I care. GNOME cares. Why are Windows and Mac OSX users more happy with respect to Chinese inputting? Honest question. I do have the confident to find out at least 100 input methods for Windows, if you want to see it. How are those 100 input methods presented to the user in Windows? Screenshots? No, they aren't. You shouldn't make such claim before you can type a paragraph independently from http://zh.wikipedia.org/wiki/Gnome Let me put it this way. Chinese may well be a fascinating language but it is not the only one which requires complex input methods or rendering. Lets not get into this you don't know my language argument. Cheers, Debarshi -- There are two hard problems in computer science: cache invalidation, naming things and off-by-one errors. pgpkGUJB9uySv.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
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 paragraph independently from http://zh.wikipedia.org/wiki/Gnome 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 not infinite. Isn't if useful to list the popular input method principles (before to work on actual input methods) ? Regards Pierre-Yves ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
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. Isn't if useful to list the popular input method principles (before to work on actual input methods) ? I wrote the following when I started working on fixing the situation for Hong Kong: http://bochecha.fedorapeople.org/chinese_ims/ Needless to say, I would **love** to add the same information from people in other regions, with other languages, etc... But even if these don't reach this specific document, it would still be very valuable to have similar things for other regions and languages. Of course, people who actually know this need to be willing to explain it, but that takes much longer than rant on a mailing-list. -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
On Fri, Nov 23, 2012 at 4:17 AM, Debarshi Ray rishi...@lostca.se 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 ones found in Windows and Mac OSX. Having more choices still make things a little better. And that's how some users now survive in Linux world and you are going to break it. I can document the current situation here: ibus-pinyin is kind of feature rich (among IBus Pinyin engines) but its language model is naive so it's conversion experience is not very good. ibus-sunpinyin uses more advanced language model so it have better conversion result, but it doesn't support Traditional Chinese nor custom phrases. ibus-rime is actually a meta engine rather than a pure pinyin engine. It has no setting GUI and require users to change its yaml configurations. You can do anything with it you are determined to do so. But the overall experience is decent so I'm using it. And it's a cross platform engine that most users probably using Windows. But has you can see, it is a perfect example of third-party engine. It's like some people go Emacs even if they have Gedit. ibus-libpinyin is a fork of ibus-pinyin with more sophisticated language model. So it is also feature rich. But it hasn't outperform ibus-pinyin much from a user's point view yet. So the user can make a choice. Just like we can make choice for programming languages, editors, ... I care. GNOME cares. Why are Windows and Mac OSX users more happy with respect to Chinese inputting? Honest question. Two things: 1. Because configuring input method are easier in Windows and Mac OSX. Our integration should be trying to solve this. 2. Because decent engines are available and easy to install. Even if I use RIME (ibus-rime being its IBus version) on both Ubuntu 12.04 and OS X 10.7. Ubuntu 12.04 requires compiling. ( I guess no Fedora package also. ) Though it is another issue, in GNOME 3.6 environment, ibus-rime will meet new challenges in the installation process. How are those 100 input methods presented to the user in Windows? Screenshots? I don't have root access to any Windows machine currently. I can ask for help if you really want it. Newly installed engines should just stay in same name space with built-in engines (I grow up with Windows then switched to Linux and OS X) Let me put it this way. Chinese may well be a fascinating language but it is not the only one which requires complex input methods or rendering. Lets not get into this you don't know my language argument. I'm not aware of any modern languages have thousands of common glyphs other than Chinese and Japanese. I do know that some languages, e.g., Hindi are harder to render. But that's unrelated. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
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.py somehow Modify /usr/share/ibus-rable/tables/quick3.db somehow Google and try hard to switch to another IMF other than IBus 2. On Mac OS X Install Yahoo KeyKey! and switch to it, done. http://tw.media.yahoo.com/keykey/ ( It's pure Chinese, more friendly to users and may be unfriendly to you guys. ) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
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.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
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 one would u drop? Yuanfang, what do you say? On Fri, Nov 23, 2012 at 7:17 PM, Ma Xiaojun damage3...@gmail.com wrote: 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.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Open Source,Open Mind Blog:http://bigeagle.me/ E-mail: bigea...@xdlinux.info ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
On Fri, Nov 23, 2012 at 5:09 PM, Debarshi Ray rishi...@lostca.se 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 of good quality engines. They do not have to go searching all over the Internet to figure out what is what, and what is more broken or less broken, and so on. If some of the engines are still lacking in features, you are welcome to improve them. Yes, that won't happen in a single day. But if you do the heavy lifting then you actually improve things instead of constantly working around things that are broken. There is a phrase called draining the swap. That is what we are trying to do here. If you think that an engine that is listed should be replaced by another because it is better than the one that is listed, then you are welcome to request that. You can even submit a patch to make that switch. Why don't GNOME maintain a whitelist for applications either? Because unlike typing and inputing with a mouse or keyboard, people do not perceive applications to be part of the OS or the desktop environment (or whatever it is that you want to call it). Do you have to choose from a dozen different drivers just to get your keyboard or mouse to work? That's obviously and completely wrong. Let me give an example u may understand: Operating Systems should just work on PCs, and Windows 8 just works, and obviously, some Linux does not support PC hardware perfectly, there is no drivers for lots of hardwares, so we have a whitelist on UEFI, and only Windows is bootable on PCs. It's ridiculous to you isn't it? and whitelisting IM engines as ridiculous to Chinese users as whitelisting OS installation on PCs. u may still don't understand, it's like there are still many people think Microsoft's UEFI whitelist is good to them because they don't use OSs other than windows. just like these people, u think whitelist is good just because u don't use Chinese IMs. so my point is, whitelist itself is wrong, the right way is remove whitelist. and how about those low quality IMs? Just let them be, IM developers will update there code so that they can be intergrated, users would just abandon IM engines which does not work, nobody cares whether it's well intergrated with gnome. 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. Or you can wait for someone else to do it for you. Cheers, Debarshi -- There are two hard problems in computer science: cache invalidation, naming things and off-by-one errors. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Open Source,Open Mind Blog:http://bigeagle.me/ E-mail: bigea...@xdlinux.info ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
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. Input methods and keyboard layouts is NOT similar in any bit. Most of the keyboard layouts are 1 to 1 key-char mapping but input method is superset to that. I hope anyone who believes that check out the Cangjie input method, since you need substantial (its a subjective word just as low-quality mentioned in previous comments) information for you to defend the whitelist approach. I am against any filtering in input method / input method engine because talking about user friendly or usability of GNOME to other high quality environment, it should be beyond the whiltelist by public, too. I personally urge GNOME devs leave the decision rights to IBus itself and its engines, or just join the IBus development and work right on it instead of hacking from GNOME. Regards, kaio On 23 November 2012 22:15, Justin Wong bigea...@xdlinux.info wrote: 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 one would u drop? Yuanfang, what do you say? On Fri, Nov 23, 2012 at 7:17 PM, Ma Xiaojun damage3...@gmail.com wrote: 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.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Open Source,Open Mind Blog:http://bigeagle.me/ E-mail: bigea...@xdlinux.info ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
s/appropriate/inappropriate/ On 24 November 2012 00:04, Caius Chance m...@kaio.net 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/blacklist to separate engines based on some criteria defined by a board is appropriate. Input methods and keyboard layouts is NOT similar in any bit. Most of the keyboard layouts are 1 to 1 key-char mapping but input method is superset to that. I hope anyone who believes that check out the Cangjie input method, since you need substantial (its a subjective word just as low-quality mentioned in previous comments) information for you to defend the whitelist approach. I am against any filtering in input method / input method engine because talking about user friendly or usability of GNOME to other high quality environment, it should be beyond the whiltelist by public, too. I personally urge GNOME devs leave the decision rights to IBus itself and its engines, or just join the IBus development and work right on it instead of hacking from GNOME. Regards, kaio On 23 November 2012 22:15, Justin Wong bigea...@xdlinux.info wrote: 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 one would u drop? Yuanfang, what do you say? On Fri, Nov 23, 2012 at 7:17 PM, Ma Xiaojun damage3...@gmail.com wrote: 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.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Open Source,Open Mind Blog:http://bigeagle.me/ E-mail: bigea...@xdlinux.info ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
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. Input methods and keyboard layouts is NOT similar in any bit. Most of the keyboard layouts are 1 to 1 key-char mapping but input method is superset to that. I hope anyone who believes that check out the Cangjie input method, since you need substantial (its a subjective word just as low-quality mentioned in previous comments) information for you to defend the whitelist approach. Its a long mail thread. Gist of issue :- Gnome can provide any IME or Input method as a default input method. No one has objection. Problem:- Gnome should allow other engines to. Right now it is not allowing. Solution(May be):- Gnome and IME developers should have a common protocol. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
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 desktop, but actually shutting the door that an IMF goes into GNOME. And killing the creative ideas in IM frameworks and engines. Because no IMF and IME can't survive if a DE refuses to accept it, no matter how brilliant your idea is. In the past GNOME doesn't care enough about IMs, then people never recognize how powerful a DE can be. These days GNOME is over compulsive so actually no IMs can fulfill its needs. So it's clear enough, GNOME has to properly describe what you need from an IM, and let IM devs do the job instead of hacking from GNOME. And you have to have some patience because actually any IM is a 3rd and independent party with GNOME. They have fewer devs than you do, you two can't keep the same schedule. IBus 1.5dev branch introduced a new API to fulfill GNOME's needs. then many of its IMs didn't catch up (They're developed by 3rd developers for IBus. That's why IBus have to develop in a slightly slow way to be mature enough for them). So you implemented a White List to filter those IMs which actually are the most advanced IMEs and have the most users. Then we're here. You thought you did good things for the end users, but they're now shouting at you. Actually you didn't listen to them and do the pre work carefully. Man, almost no one use ibus-pinyin nowadays...a default means to be fast, to be light, and to be good integration with the IMF. But end users need more functional and feature full ones. You blacklisted them. So you pushed them into fire. You're doing things in a reverse way. It should be GNOME who tries to be compatible with nowadays stable IBus instead of pushing everything. But now it's useless to talk about that schedule, theory or protocol stuff. We have to figure out why GNOME implemented that white list filter, and how to get those IBus input methods into the white list. That's the point of the argument. Greetings, Marguerite ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fallback mode is going away - what now ?
On Fri, Nov 23, 2012 at 4:04 AM, Allan Day allanp...@gmail.com wrote: Matthias Clasen matthias.cla...@gmail.com 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 thing, setting this up will require a number of settings to be tweaked (e.g. the one for the minimize button), and alternative sessions don't have the right infrastructure for that. 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. The session chooser on the login screen is not the best designed part of the login experience either. That's a non-argument. We can improve it. Indeed, that is https://bugzilla.gnome.org/show_bug.cgi?id=658593 The Tweak Tool is *completely* the wrong place for this. In what way is completely changing the shell a tweak? How does it make sense to be able to completely change the experience using a setting that is included in a non-core application, and which could later be removed? What kind of experience will you get when the shell transitions to classic mode right in front of the user's eyes? 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. We may have to look over the tweak tool, then - enabling and configuring extensions is currently very much part of it. Thanks for chiming in; I appreciate it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fallback mode is going away - what now ?
On Fri, Nov 23, 2012 at 5:59 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Fri, Nov 23, 2012 at 4:04 AM, Allan Day allanp...@gmail.com 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 probably add a little session-mode hook to load extensions in addition to the ones configured in GSettings, so running gnome-shell --mode=fallback (or classic if we must) would start with the appropriate extensions (including a simple one that overrides the location of the button-layout setting to include the minimize button in the default). But is this really what we want? Separate sessions strongly indicate that we provide two different but equal user experiences, rather than a variation of the default experience which throws in some familiar bits to make the transition less painful. Or am I misunderstanding something and we indeed intend to provide the former? 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 not the right place for extension management, I don't think this is much of a concern with the matter at hand - as I understand it, extensions are merely an implementation detail here and not exposed to the user (except that they should also appear separately on extensions.gnome.org, so users don't have to switch their system over entirely if they only care about one or two tweaks). As mentioned briefly above, I'd still assume an implementation based on extensions even if we are going for a separate session. Florian (*) not to mention an extension management extension - I wish I was kidding ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fallback mode is going away - what now ?
Florian Müllner fmuell...@gnome.org 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 not the right place for extension management, I don't think this is much of a concern with the matter at hand - as I understand it, extensions are merely an implementation detail here and not exposed to the user (except that they should also appear separately on extensions.gnome.org, so users don't have to switch their system over entirely if they only care about one or two tweaks). As mentioned briefly above, I'd still assume an implementation based on extensions even if we are going for a separate session. ... (*) not to mention an extension management extension - I wish I was kidding Yeah, we sorely need a way to locally enable/disable and uninstall extensions. This should be built into the core, somehow. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fallback mode is going away - what now ?
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 technical issues (shoddy/broken network, pushing browsers to the limits, potential security problems with native code, broken by the click to play plugins model) prevent it from being as fluid and well-implemented as I had hoped. Right now, the local experience for this is use gnome-tweak-tool, which has a native UI or use the Extension List extension. If you want to design something better, feel free. I've been trying to get designers involved in the design of the website and extensions experience, but I haven't gotten any reception whatsoever from the 4 or 5 times I've tried to bring it up, so I dropped. But this is getting off-topic. I wrote a giant rant as a G+ comment on some post that someone made about this mailing list thread. Summary: I don't feel the classic mode experience is a great long-term solution, but since we're used to just writing and shipping untested code, it's going to be what we do for now. On Fri, Nov 23, 2012 at 1:27 PM, Allan Day allanp...@gmail.com wrote: Florian Müllner fmuell...@gnome.org 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 not the right place for extension management, I don't think this is much of a concern with the matter at hand - as I understand it, extensions are merely an implementation detail here and not exposed to the user (except that they should also appear separately on extensions.gnome.org, so users don't have to switch their system over entirely if they only care about one or two tweaks). As mentioned briefly above, I'd still assume an implementation based on extensions even if we are going for a separate session. ... (*) not to mention an extension management extension - I wish I was kidding Yeah, we sorely need a way to locally enable/disable and uninstall extensions. This should be built into the core, somehow. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fallback mode is going away - what now ?
On Fri, Nov 23, 2012 at 7:27 PM, Allan Day allanp...@gmail.com wrote: Florian Müllner fmuell...@gnome.org 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 not the right place for extension management, I don't think this is much of a concern with the matter at hand - as I understand it, extensions are merely an implementation detail here and not exposed to the user (except that they should also appear separately on extensions.gnome.org, so users don't have to switch their system over entirely if they only care about one or two tweaks). As mentioned briefly above, I'd still assume an implementation based on extensions even if we are going for a separate session. ... (*) not to mention an extension management extension - I wish I was kidding Yeah, we sorely need a way to locally enable/disable and uninstall extensions. This should be built into the core, somehow. Really? Because I have all that code written and sitting there in tweak-tool and have held off enabling/presenting it for fear of stepping on the toes of e.g.o and confusing everyone. If you want me to put that into tweak-tool just ask. BTW; this gets a bit messier if now we ship classic mode as a collection of system-wide (i.e. package manager installed) extensions instead of the user-only extensions aka e.g.o. John Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Concerning Keyboard Status Menu
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 GNOME 3.4, Fedora 17 and GNOME 3.6, Fedora 18 (installed from Alpha and did entire system update), respectively. http://dl.dropbox.com/u/45139465/gnome34.webm http://dl.dropbox.com/u/45139465/gnome36.webm ( There is no sound/voice at all. And I'm not savvy in video tutorial business at all. ) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
