Re: Heads up: Geary mainline development branch renamed to `mainline`
On Fri, 2019-04-26 at 10:38 +0200, Niels De Graef via desktop-devel- list wrote: > Note that you don't need to script this kind of stuff, if you use the > following tricks: > > # 1. This creates a symbolic link from master to mainline, which > solves your problem already. > $ git symbolic-ref refs/heads/master refs/heads/mainline > > # 2. This worfklow doesn't even need you to specify a branch if you > start from mainline/master > $ git checkout -b feature/ > # work, work, work and commit > # If you no longer want to continue on this branch, you can go back > to the previous one with > $ git checkout - # 3. Tab completion works wonders: $ git checkout ma Mike said himself that choosing a new name starting with the same letters as "master" was a deliberate choice to further minimize the disruption. -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] IMPORTANT: Mass migration plan
On Wed, 2018-03-21 at 11:22 +0100, Arnaud Bonatti wrote: > Hi Milan, > > 2018-03-21 8:53 UTC+01:00, Milan Crha : > > Your module rename may mean also renaming in distributions, thus it > > should not be done in a rush and "just because we can". At least > > from my point of view. You also lose some kind of mind share with > > the rename, because existing users know what it is called now, but > > will be lost when you rename the module […] > > I completely agree with you, the renaming of an old and known > application is always a hard thing to decide and to do, and that’s > why it definitively needs discussions. Note that I don’t feel any > hurry here (in fact, I’m talking here and there about this renaming > since two years…), but depending on how hard it looks like to do the > renaming *after* the Gitlab migration, Renaming in Gitlab is trivial: in the project settings you can just rename the project, and Gitlab will set up redirections so that old URLs keep working. (at least that happened on other Gitlab instances, I see no reason why that wouldn't work on GNOME's) -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] IMPORTANT: Mass migration plan
On Wed, 2018-03-21 at 06:28 -0400, Carlos Soriano wrote: > > Any chance of getting > https://gitlab.gnome.org/Incubator/bztogl/issues/7 fixed before then? > > Not sure, I think impersonating is still something some people don't > agree with. It's what the Gitlab "Import from Github" feature does, automatically, by default. I've never met anybody complaining about this, and on the contrary have always seen people being extremely positively surprised that Gitlab managed to preserve authorship of everything (tickets, pull requests, etc… i.e not just commits) Of course, that's just anecdata… Have you actually had anyone complaining about it? -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, 2017-08-25 at 19:13 +0100, Matthew Hodgson wrote: > My proposal is that one could run a background daemon on Linux which > brokered the connection to your Matrix server (and perhaps handled > fun stuff like clientside history persistence, e2e encryption voodoo, > WebRTC audio playback/capture etc) and then expose that as part of > the OS to desktop apps - effectively as a next gen telepathy > equivalent. Why bother with a Matrix server at all? Couldn't that local daemon effectively be the Matrix server? -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Building GNOME in restrictive network environments
I just fixed all the .json manifests and .app files in the master branch of gnome-apps-nightly, as well as the .json manifest for the master branch of the GNOME Sdk. -- Mathieu On Mon, 2017-07-31 at 15:40 +0200, Mathieu Bridon wrote: > I've just gotten bitten by this as well, and have started moving all > the ones in gnome-apps-nightly from git:// to https:// > > > -- > Mathieu > > On Mon, 2017-07-31 at 14:15 +0100, Bastian Ilso wrote: > > We also experienced this issue at the newcomers workshop as many > > flatpak manifests also download dependencies using the git:// > > protocol. It'd be great to have these fixed or maybe have a > > fallback > > behavior (having several URLs to try in the manifests?). > > > > > > -Bastian > > > > > > On Mon, Jul 31, 2017 at 1:29 , mcatanz...@gnome.org wrote: > > > Hi all, > > > > > > I've gotten multiple complaints at GUADEC that it's not possible > > > to > > > clone GNOME modules because the university network is blocking > > > the > > > git protocol. This is particularly common at universities in > > > third- > > > world countries, where it's common for newcomers to complain > > > about > > > this, but seems it happens in Europe too. So I have changed > > > JHBuild > > > to clone stuff using https:// rather than git://. I'm testing > > > this > > > now and will push as soon as I'm sure I haven't broken anything. > > > > > > Cav eats: > > > > > > * I have not updated all of gnome-world, so contributions are > > > welcome there as usual. But all the supported 3.26 modulesets > > > should now be completely fixed. > > > > > > * Some modules clone git:// submodules. Please be on the lookout > > > for these. For example, this is .gitmodules in gnome-online- > > > accounts: > > > > > > # Bad > > > [submodule "telepathy-account-widgets"] > > > path = telepathy-account-widgets > > > url = git://git.gnome.org/telepathy-account-widgets.git > > > > > > It's better to clone using the same protocol as the parent > > > project: > > > > > > # Good > > > [submodule "telepathy-account-widgets"] > > > path = telepathy-account-widgets > > > url = ../telepathy-account-widgets.git > > > > > > I'll leave it to module maintainers to fix these. > > > > > > Thanks, > > > > > > Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Building GNOME in restrictive network environments
I've just gotten bitten by this as well, and have started moving all the ones in gnome-apps-nightly from git:// to https:// -- Mathieu On Mon, 2017-07-31 at 14:15 +0100, Bastian Ilso wrote: > We also experienced this issue at the newcomers workshop as many > flatpak manifests also download dependencies using the git:// > protocol. It'd be great to have these fixed or maybe have a fallback > behavior (having several URLs to try in the manifests?). > > > -Bastian > > > On Mon, Jul 31, 2017 at 1:29 , mcatanz...@gnome.org wrote: > > Hi all, > > > > I've gotten multiple complaints at GUADEC that it's not possible to > > clone GNOME modules because the university network is blocking the > > git protocol. This is particularly common at universities in third- > > world countries, where it's common for newcomers to complain about > > this, but seems it happens in Europe too. So I have changed JHBuild > > to clone stuff using https:// rather than git://. I'm testing this > > now and will push as soon as I'm sure I haven't broken anything. > > > > Cav eats: > > > > * I have not updated all of gnome-world, so contributions are > > welcome there as usual. But all the supported 3.26 modulesets > > should now be completely fixed. > > > > * Some modules clone git:// submodules. Please be on the lookout > > for these. For example, this is .gitmodules in gnome-online- > > accounts: > > > > # Bad > > [submodule "telepathy-account-widgets"] > > path = telepathy-account-widgets > > url = git://git.gnome.org/telepathy-account-widgets.git > > > > It's better to clone using the same protocol as the parent project: > > > > # Good > > [submodule "telepathy-account-widgets"] > > path = telepathy-account-widgets > > url = ../telepathy-account-widgets.git > > > > I'll leave it to module maintainers to fix these. > > > > Thanks, > > > > Michael > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pilot GitLab program
Hi, On Wed, 2017-06-28 at 08:42 +0200, Milan Crha wrote: > On Tue, 2017-06-27 at 10:54 +0200, Carlos Soriano wrote: > > We’ve been collecting the feedback on this wiki page: > > https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/Commun > > ityInput > > c) I generate NEWS file from `git log`, which is also the reason why > commit messages are made the way they are. It saves plenty of >time. With the "closes #NNN", will it still be possible? Where is >the "closes #NNN" meant to be, anywhere in the commit message? Yes, you can put it anywhere in the commit message. And do note that you don't have to use « Closes #NNN », you can also use « Closes https://./NNN ». Put that on its own line to make it more readable to human, replace « Closes » by « Fixes » (one less letter to type :P ) and you get something very close to the current practice of referencing Bugzilla tickets in commit messages. :) -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pilot GitLab program
On Tue, 2017-06-27 at 08:08 -0500, Michael Catanzaro wrote: > On Tue, Jun 27, 2017 at 3:54 AM, Carlos Soriano > wrote: > > Expect Nautilus and librsvg (with Federico) to move to the pilot > > program this week. > > Cool. I would just suggest making sure that your interns are careful > not to push a non-ff merge (i.e. not to use merge requests), since > that will confuse nautilus's git history until the end of time. A > server hook to block this would be useful, Gitlab allows protecting branches. Look into the settings of each project to find it. :) -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, 2017-05-23 at 15:13 +0300, Adrian Perez de Castro wrote: > Hi there, > > No strong opinion here about GitLab, just a comment below... > > On Tue, 23 May 2017 11:21:25 +0200, Felipe Borges il.com> wrote: > > > [...] > > > > Cons: > > - not a big fan of the merge-request workflow > > - we will have a bunch of useless forks across the users' accounts > > I have seen this concern pop several times in this thread. Does > GitLab strictly require that a merge request is always started from a > fork? No, this works exactly like in Github. > At least with GitHub and Gogs [1] it's possible to create merge > requests from a branch *in the same repository* (I use branches named > “/” now and then). If everybody who is a > maintainer is going to have push access in the GNOME GitLab instance, > they can just push their branch to repository and create the merge > request from there — without needing to fork the repository into > their user space. Exactly. Only new contributors who don't have the permissions yet would need to create their own forks. -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 17:44 +0200, Jehan Pagès wrote: > On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon > wrote: > > On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote: > > > IMO this is a completely broken and over-complicated workflow. > > > For > > > long term contributors, having their own remote can be > > > understandable. > > > But for one-time contribs? > > > > One-time contributions can be done entirely in the web UI, for > > example: > > Ok. Sorry but no. > I code in my text editor, not in my browser. That's fine, me too. But you're not a one-time contributor to GNOME, are you? Remember that I'm responding to your thread about how the fork+merge- request workflow is too complex for trivial one-time contributions. > > For one-time contributions, this is a **much** simpler workflow > > than cloning the repository, making the changes, committing the > > change, making a patch, then sending the patch by email/bugzilla. > > It even enables non-technical people to contribute! > > Well much simpler for developers who like to push buttons. We are > many who don't like this. Let's not generalize! > > Also such patches are acceptable for very simple stuff. For instance > typo fixes, or string fixes, or similar. Well yes, that's exactly what this thread was about: simple one-time contribution that are so trivial that they make the fork+merge-request workflow prohibitive. > But other than this, even > one-liners of actual code, I don't want to encourage people who do > things without actually testing (and expecting us to test for them). That's why you have a CI that runs before merging. > > And if I send you a patch, you might find it easier to test it > > locally. But that completely bypasses your pre-merge CI. > > CI test basic stuff like "it builds", and "the tests don't fail". But > there is much more in a patch than this. A CI can do pretty much anything you want it to, it's not limited to "basic stuff" at all. > Of course, you could say that the tests should include every case. > But the fact is that if there is a bug that was not seen before, that > probably means there is no tests for it (otherwise we'd have seen > it!). Even if we add a test, then we have to check first that the > test is fine by building locally. Back to square 1. And the person doing that is not the one-time contributor, but you, the maintainer. Seriously, you started complaining that the fork+clone is too complex for trivial one-time contributions, and now you've completely changed the goal-posts, complaining how the wokflow that was specifically designed for trivial one-time contributions doesn't allow bigger changes. -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote: > IMO this is a completely broken and over-complicated workflow. For > long term contributors, having their own remote can be > understandable. > But for one-time contribs? One-time contributions can be done entirely in the web UI, for example: 1. find the file in the source code you want to modify 2. click the "edit" button 3. "You don't have permission to edit this file. Try forking this project to edit the file." -> click the "fork" button 4. you get presented with a web-based editor for the file you wanted to edit, in your fork, do your changes, write a commit message, click "commit changes" 5. this **automatically** opens a form to create a merge request, you can just submit it For one-time contributions, this is a **much** simpler workflow than cloning the repository, making the changes, committing the change, making a patch, then sending the patch by email/bugzilla. It even enables non-technical people to contribute! And if I send you a patch, you might find it easier to test it locally. But that completely bypasses your pre-merge CI. With a pull-request, your CI can run **before** merging any change, which means you can try and keep master always building and with passing tests. -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, 2017-05-17 at 15:55 +0200, Bastien Nocera wrote: > If I'm a registered developer for the GNOME org, or that particular > module, I'd create my merge requests as wip branches in the main > repo?Or as branches in a separate repo that I have the control of? That would be up to you. Choose whichever you prefer? > What about developers that don't have GNOME commit access? Do they > fork, play in their corners and then create a merge request? Yes. > Does that merge request automatically create a branch in the upstream > repo? No. However the merge requests get added as refs in the remote git repo, so you can fetch them locally: https://docs.gitlab.com/ce/user/project/merge_requests/index.html#check out-locally-by-modifying-git-config-for-a-given-repository Alternatively, you can add a remote pointing to the fork, then fetch that to get the branch to merge. > > > > - git-bz attach equals to git push origin HEAD:fix2340issue, > > > > then click create merge request. > > > > > > Does this rewrite the commit message to include the PR or bug > > > number? > > > > No, as written in the wiki you write "Closes: $number" and it will > > handle things automatically. > > Of course some addition could be done to do the rewrite. > > Right, so that's not automated, and you can't know what to put in the > commit messages until you've create the merge request. Kind of a > chicken and egg problem. The merge request gets automatically closed when you merge it. The "Closes #number" is to associate the commit to the corresponding issue (and have it closed automatically), not the pull request. > > > Do we end up with separate merge requests and bug numbers, > > > segregating users and developers? And yes, clicking a button is a > > > problem when > > > > Yes. They are different concepts in this tool, which I though it > > was an improvement. The bug is more about the discussion of what is > > wanted/motivation/reasoning/design/etc., the merge request is about > > pure code. > > Not sure I would frame it as segregating users and developers > > though. > > As Jehan mentions, it is. Users filing bugs look at open issues, most > of the time, but don't look at merge requests at all. Searching in a repo will give results both in the code, the issues, the merge requests, the wiki, ... -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Stackexchange community for GNOME/GTK+
On Wed, 2017-05-10 at 09:30 -0400, Carlos Soriano via desktop-devel- list wrote: > Is there some public place that offer something similar as AskFedora > to create a community for GNOME? > I think one requirement for us is to not host it ourselves, and still > be relevant. > I guess that's why Sri choose Stackexchange. But I don't know other > alternatives. I'll just point at this: https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedo raproject.org/message/6IWBLCCLAKLEGQCOGL3KADCJK4OGARQV/ Fedora has been using AskBot for some time, and it's proving painful to host. The main developer seems to be willing to help though, including with providing hosting. -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome "opt-in" functionality.
Hi, On Fri, 2016-09-16 at 11:00 +0100, Sam Thursfield wrote: > You can disable Tracker's background indexing fairly easily, if you > don't mind that some things will get broken. In most distros, if you > move the files /etc/xdg/autostart/tracker*.desktop somewhere else, > then the Tracker processes won't start when you log in any more. And then an update to the tracker package would add those files back. The better way is to copy those files into your ~/.config/autostart/ and modify them so that tracker doesn't start. I think adding Hidden=true does it. Or instead configure tracker to not index anything, with the Search settings panel. Tracker would still be running, but it wouldn't do anything at all so it shouldn't consume any resource. (and if it still does, then file a bug report) -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: builddir != srcdir in jhbuild breaks my workflow
On Fri, 2016-09-02 at 08:09 +, philip.chime...@gmail.com wrote: > On Thu, Sep 1, 2016 at 5:43 AM Michael Catanzaro g> wrote: > > On Tue, 2016-08-30 at 21:25 +, philip.chime...@gmail.com wrote: > > > I've been thinking about the exact same thing recently; how about > > a > > > 'jhbuild jump' command that will take you from a location under > > > srcdir to > > > the corresponding location under builddir and vice versa? And > > perhaps > > > have > > > some environment variables defined as well. > > > > It could run 'jhbuild shell' if UNDER_JHBUILD is unset, then do the > > jump. That would be useful. > > I soon ran into the should-have-been-obvious-in-hindsight limitation > that you can't change the parent process's working directory from a > jhbuild command. In the python world we have `pew`, which allows to maintain effortlessly your virtual environments. Virtual environments are like the Python equivalent of the jhbuild shell. One thing that is amazing with pew is that it provides a $ pew workon $project command which both activates the virtualenv **and** move you to the source directory of the project you asked to work on. Which sounds similar to what you'd like for `jhbuild jump` (except that would place you into the builddir, not the scrdir). The way pew does that it simply runs a new shell in the right working directory. Couldn't `jhbuild jump` do the same? In python that's as simple as: $ python3 Python 3.5.1 (default, Aug 9 2016, 15:35:51) [GCC 6.1.1 20160621 (Red Hat 6.1.1-3)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> import subprocess >>> >>> os.getcwd() '/home/mathieu' >>> >>> subprocess.check_call(['bash'], cwd='/tmp') $ pwd /tmp $ exit 0 >>> -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: help needed for OSK layout files
On Mon, 2015-01-19 at 15:46 +0530, anish patil wrote: > On Mon, Jan 19, 2015 at 3:35 PM, Mathieu Bridon > wrote: > >Would it make sense to add Caribou layouts for input methods? > > >For example, the Cangjie input method uses the en_US layout. > However, it > >associates a Chinese radical to each Latin letter on the > en_US layout. > > >We can't do that with physical keyboards, but with an OSK, it > could be > >nice to display not the Latin letters in such a case, but > instead the > >Chinese radicals associated to each? > > I am not sure that is would be possible or not, because we have more > than 2500 Chinese characters and in some cases users forms complex > Chinese characters with combination of other characters. I know. That's why I was talking about a specific example (Cangjie), where each key has a specific character associated to it. Combinations of characters are a second thing, which is already handled by the rest of the stack (IBus, engines, GNOME Shell to display the candidates popup and the preedit/auxiliary texts,...) -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: help needed for OSK layout files
Hi, On Mon, 2015-01-19 at 15:49 +0900, Daiki Ueno wrote: > Hello, > > There is a long-standing request that gnome-shell OSK should respect > system's keyboard layout[1]. Though actually it works already, we are > still missing the majority of layout files (see > /usr/share/caribou/layouts/touch/*.xml; there are only 3). I'd like to > call for more layout files submitted, hopefully in the 3.16 cycle. > > I understand that writing a layout file from scratch is an uphill task. > On the other hand, the Unicode CLDR repository provides an extensive set > of OSK layouts for platforms including Android, Chrome OS, and Mac OS X. > > So, as a first step, I wrote a procedure for creating a layout file > based on the CLDR data: > https://wiki.gnome.org/Projects/Caribou/NewLayout > > If you come up with a new layout, please file it against the 'caribou' > product on bugzilla. I have no expertise in design but should be able > to do a quick review. Would it make sense to add Caribou layouts for input methods? For example, the Cangjie input method uses the en_US layout. However, it associates a Chinese radical to each Latin letter on the en_US layout. We can't do that with physical keyboards, but with an OSK, it could be nice to display not the Latin letters in such a case, but instead the Chinese radicals associated to each? -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Clone of 2048 for Gnome
On Thu, 2015-01-08 at 11:24 +0100, Alexandre Franke wrote: > On Thu, Jan 8, 2015 at 12:30 AM, Marc-André Lureau > wrote: > > - wouldn't it be nice to have some kind of congrats feedback when you > > reach 2048? > > That's the single thing that annoys me with the original 2048: when I > reach 2048 (which is quite often now) and want to keep on going, I > have to stop, grab the mouse and click on a button before I can resume > playing on the keyboard. Feedback is ok, but don't make it a > disruptive one. Another version I played would have the disruptive congratulation the first time you'd reach 2048, then it wouldn't do it anymore. It would again congratulate you the first time you'd reach 4096, but only the first time as well. Then... I don't know, I never reached 8192. :) -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RFC: GSound, a GObject library for playing system sounds
Hi, On Fri, 2014-11-14 at 17:47 +0800, Tristan Brindle wrote: > A little while ago I wrote a small library called GSound (remarkably, a name > which doesn’t seem to have been used before, at least on my Fedora > installation). It wraps the libcanberra API and “GObject-ifies” it so it can > be properly used in introspected languages. I’ve recently dug it back up and > dusted it off ready for public release. The code is available at > > https://github.com/tcbrindle/gsound > > and the generated documentation can be found at > > https://tcbrindle.github.io/gsound-docs > > (libcanberra itself isn’t introspectable, which I believe has caused problems > for various projects in the past, and is the reason GSound exists.) It certainly has. I for one would be very happy to use GSound in IBus Cangjie (which is written in Python) instead of relying on the not-so-great pycanberra. (no support for the other introspected languages, based on ctypes, inactive upstream,...) Please, do make GSound an official part of GNOME, so we can start depending on it. :) -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgsystem as a shared library
On Wed, 2014-02-05 at 11:24 -0500, Jasper St. Pierre wrote: > I mean, copylibs have existed forever, usually by just copying files > around from project A to project B, and back from project B to project > A. Why does structuring this process in a git submodule make it > suddenly illegal in Fedora review? I'm pretty sure it doesn't: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Copylibs I've reviewed a couple of GNOME apps using libgd, and every time all I asked in that regards was: 1. the package must filter its automatic provides so that it doesn't end up providing libgd (as it's not a shared library for other packages to use) 2. the package must have "Provides: bundled(libgd)" Which is pretty much what the above guidelines says. -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Wed, 2013-04-24 at 04:00 +0300, Luc Pionchon wrote: > On 24 April 2013 02:14, Florian Müllner wrote: > > On Tue, Apr 23, 2013 at 11:09 PM, Marco Scannadinari > > wrote: > > > I think your suggestion of a "feature" branch can be a worthy > > compromise, though. > > > > Except that Bastien is right - while on a branch, a feature will > > hardly be tested by anyone than other core developers of the same > > module. It's unfortunate, but "real" users generally only get to test > > a new feature once it appears in their distro (read: some time after > > the feature appears in a stable GNOME release). > > > A branch can be packaged as well. > > So one module could have two packages. Who will package them? For which distros? With how much delay? > One with "mature" UI changes. > One with "controversial" edge UI to be tested. Now consider the many modules forming GNOME. Do you build the "edge" package of, say, GNOME Shell against the "mature" package of GLib? Or also against the "edge" of GLib? Such a solution would quickly lead to an explosion of possible combinaisons of edge/mature packages. Unless you mean that a user must install the "edge" package for all modules if all they want is to test the "edge" of GNOME Shell? If so, how is that different from just installing the 3.9 packages in a development distro? -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: The name of applications on GNOME 3.7.92 testing image
On Saturday, March 23, 2013 02:11 AM, Maciej Piechotka wrote: On Fri, 2013-03-22 at 12:51 -0400, Jasper St. Pierre wrote: gedit is becoming more of a programmer's editor, so the gedit team wants to keep the "gedit" brand while people work on a new simple Notepad-equivalent that will be called "Text Editor". What would be a use case for such application? Most people (based on my own, 100% certain guess ;) ) who use text editors are willing to deal with small extra complexity of GEdit/notepad++/... as compared to Windows notepad. For those who don't there are specialized options like notes or whatever replaces Tomboy. I fail to see why GEdit would be more complicated for 'normal' users then notepad. Most people I know use a word processor (MS Word, LibreOffice Writer,...) when they want to write text, even for quick things without formatting. I don't think a **simple** text editor à-la Notepad really is that useful for anybody. It might even be confusing for many people. Try to explain the difference between a "word processor" and a "text editor" for example. Usually, the next question is « But then what's the point of something that lets you type simple text, but without any formatting? » I personally have no idea of the answer, as like you said, there are (or will be) dedicated apps for the interesting use cases (e.g note-taking). -- 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 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 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 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 Friday, November 23, 2012 11:11 AM, Ma Xiaojun wrote: On Thu, Nov 22, 2012 at 8:09 PM, Mathieu Bridon wrote: Could it be because none of them are of sufficient quality that they feel the need to constantly try new ones, in the hopes that it will be better than the rest? Yes, but the closed-source Windows engines basically outperform current IBus engines currently. That's just a bug, let's fix it. But for Pinyin, Wubi and probably some others are much harder. You seem to know how these could be fixed, why don't you do it, or help others who could? Instead, we should try to do things. 1. Keep the IBus platform open to third-party engines. It actually is open to third-party engines. Also, when you say "users", who are you talking about? Linux users, who are generally more eager to tinker and try stuff? Or the more general population who only use computers as a tool to get something done? Don't be bad to Linux geeks. What part of my message lead you to believe this? There was absolutely no moral judgement in my message. (I mean, I actually **am** a Linux geek) I don't have much experience with computers in work space, Mainland. But for personal Windows I met, none of them are using Windows built-in engines. Is it because the built-in engines in Windows suck, or because people just enjoy trying new stuff all the time? -- 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 Friday, November 23, 2012 07:39 AM, Ma Xiaojun wrote: In case you don't know. Unlike other language groups, Chinese users are used to the fact there are many third-party engines available for same input scheme and they would make a random or non-random choices between them. Could it be because none of them are of sufficient quality that they feel the need to constantly try new ones, in the hopes that it will be better than the rest? Also, when you say "users", who are you talking about? Linux users, who are generally more eager to tinker and try stuff? Or the more general population who only use computers as a tool to get something done? -- 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
[Note: I'm not a GNOME developer, I don't have Git access, I'm not part of any conspiracy, but I'm actively working on improving the inputting experience for Traditional Chinese in Hong Kong] On Thursday, November 22, 2012 05:01 PM, Ma Xiaojun wrote: However, why the menu in keyboard status menu become something that requires engine specific hacks? I saw one for anthy. https://bugzilla.gnome.org/show_bug.cgi?id=682314 http://git.gnome.org/browse/gnome-shell/commit/?id=9659d934ac190a6363fc5b59f3c62ef305f56c52 What about ibus-chewing, ibus-pinyin, ibus-table and probably other engines especially 'third-party' ones then? Without property menu they are much less useful in practice. If you have concerns the property texts, other things about 'supported' engine, why don't you contact IBus upstream and request for change? ibus-table had no upstream for a very long time. I know it, because I spent weeks trying to find who was the upstream maintainer (and IBus people didn't even know) until kaio recently took it over. (I can't be grateful enough to him for this) How can GNOME (well, mostly one developer and one designer) track all the upstreams of all the engines, when some don't even have upstreams at all? Also, and that's a more general observation, GNOME 3.6 is **the first time** there is any kind of integration of the input methods. Did you really think it would be perfect the first time? There will be improvements in 3.8 and beyond, I'm sure Rui has a TODO list that extends to the next few years. :) And part of these improvements is for people who actually use input methods to come and explain GNOME people what would be a great user experience for their language. That's probably why Anthy has these integration points: because some Japanese people (users and developers) came together and gave feedback on what their inputting experience should look like. That's what we've been doing in Hong Kong for the past few months too, both in discussing locally when we meet, and talking with Rui and Allan about what we needed. (and we're not as well off as Anthy users for 3.6 because we're starting from a worse point, and we don't have as many knowledgeable people here). And that's what people who care about the user experience for their languages should do. Because ultimately, only them can do it. There is no way a non-Chinese designer (as good as he is) can figure out on his own the perfect user experience to input Chinese. Chinese people have to help him design that user experience. And at least for Hong Kong, it's going on very well. (although slower than I would have hoped, but the ball is on our side) It will take time, but it's going to work out eventually and provide a truly great user experience. Now I know you have some solid programming skills as we've worked together on some changes to ibus-table in the past. So please, let's write less emails, and more patches, to make IBus better, both inside and outside of GNOME. :) Cheers, -- Mathieu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
