gnome-shell (clutter) on EGLDevice
Sorry if this is incorrect list. I'm trying to debug why my Gnome fallbacks to X11. All I get is cryptic message: Aug 07 00:33:32 babylon5 gnome-shell[3616]: g_strsplit: assertion 'string != NULL' failed Aug 07 00:33:32 babylon5 gnome-shell[3616]: g_strsplit: assertion 'string != NULL' failed Aug 07 00:33:32 babylon5 gnome-shell[3616]: Unable to initialize Clutter: Unable to initialize the Clutter backend: no available drivers found. Aug 07 00:33:32 babylon5 gnome-shell[3616]: Unable to initialize Clutter. Does anyone knows what the problem might be (I tried to gdb into gnome-shell but it hanged terminal)? Maciej (Matthew) PS. Is attaching display to dGPU with EGLDevice while GEM/iGPU drives primary display meant to work? I see primary display blinking but that's it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
On Fri, 2014-08-22 at 08:47 +0100, Allan Day wrote: Hi all, A new version of the HIG is in the works, to be released along with GNOME 3.14 [1]. I'm currently looking for feedback. I'm particularly interested to know if anything is missing, confusing, or incorrect from a technical point of view (like if any of the recommendations are impossible or very difficult to do with current GTK+). To read the latest version, just clone gnome-devel-docs and open hig3/C/index.page with Yelp. Thanks! Allan [1] https://blogs.gnome.org/aday/2014/08/21/new-human-interface-guidelines-for-gnome-and-gtk/ Please note that while I plan to write a small app in near future I have 0 experience with GTK+ and even less with the design so I might simply misunderstood something: - Code samples or links to the GTK+ documentation would be nice as I imagine some UI elements are named for their role rather then the GTK+ widget. Probably the samples are too much work in 3.14 timeframe but links to documentation would be nice (for example should sidebar be implemented by GtkPlacesSidebar?) - Sidebar lists image shows primary windows and application menu - I guess different image was intended. - Possibly middle mouse button should be discouraged as well due to confusion with scroll events some mouses have. I had 'fun' using one application (not in Gnome) where some basic operation was only accessible through this method. - Some sections seems to be meant to be 'obligatory' for beginners (Essentials or Getting Started) - it would be nice to have next/prev link instead of relaying on back/next button in yelp Best regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
On Fri, 2014-08-22 at 17:04 +0200, Tobias Mueller wrote: Hi. On Fri, Aug 22, 2014 at 08:47:50AM +0100, Allan Day wrote: A new version of the HIG is in the works, to be released along with GNOME 3.14 [1]. I'm currently looking for feedback. I've pushed an HTML version here for your convenience: http://people.gnome.org/~tobiasmue/hig3 Please note that this a one-shot effort and will likely not see any updates. Do we have automatically compiled versions somewhere? I don't know much about yelp but it looks like no compilation is necessary - git clone and direct opening of page worked for me. % git clone git://git.gnome.org/gnome-devel-docs --depth 1 % yelp gnome-devel-docs/hig3/C/index.page Cheers, Tobi Best regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sun, 2014-08-03 at 19:38 +, David Woodhouse wrote: On 08/02/2014 10:38 AM, David Woodhouse wrote: If I use git correctly and push the *merge*, however, then my original work is preserved. Someone later trying to work out what happened has actually got a correct version of history to refer back to, and the problem can be correctly tracked down to the *merge* of the concurrent changes. Except that this correct version of history looks like this: - Implement X - Implement Y - Implement Z - Make a whole bunch of changes all at once, some of which are related to X, some to Y, some to Z, and some to more than one of them, and without any indication of which changes relate to which commit so no one in the future will ever be able to figure it out ha ha ha. Which sucks. So I'll stick with rebasing, thanks. That is so far from the normal experience of using git as intended, that I don't quite recognise it. It sounds like you've had a bad experience of someone doing something truly bizarre and ill-advised, and it's put you off doing things *correctly* for ever more. Much like the libxml2 insanity with quantum symbol versioning seems to have put people off using *that* properly. Or indeed at all. But I wasn't necessarily expecting the don't use git properly policy to be changed - it's just that nobody seemed to be acknowledging the elephant in the room in this thread, which was that the whole problem being discussed is an artificial one purely caused by that policy. So I felt it appropriate to make sure it was mentioned. I don't think the 'using git as intended' is a clear-cut thing. I guess it's reasonable to assume git was intended for Linux kernel development workflow where the linux-next is managed by Linus, who pulls the commits from lieutenants who pull the data from branches. Even in such situations IIRC the people are adviced to just rebase on feature branches to avoid the myriad of merge commits. Maintaining of Linux kernel is a bit more complicated then Gnome modules - I'd imagine that we would have corresponding situation when we would have a whole Gnome in single git repository and gtk+ development would happen in separate branch while i18n could have a separate branch. When the release of new Gnome would come a release team would pull the changes in and make a release. This is not a way which makes sense for Gnome though it makes sense for Linux as we can and are more modular. My guess would be to do it in 'Linux' way and avoid multiply merge commits would be to push the i18n to separate branch and make the maintainer, though I would imagine to be much more complicated for our purposes. -- After some digging about usage of git in Linx: LWN article http://lwn.net/Articles/328436/ - Linus does not tell developers not to use it [rebasing]; in fact, he encourages it sometimes., On the other hand, private history can be rebased at will - and it probably should be.. Original Linus post http://lwn.net/Articles/328438/ - So you can go wild on the git rebase thing on it, Keep your own history readable Best regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Power switch to actually turn off my computer
On Thu, 2014-04-10 at 14:46 +0200, Florian Müllner wrote: On Thu, Apr 10, 2014 at 2:34 PM, Charles T. Smith cts.private.ya...@gmail.com wrote: Do you suppose that kde also manages the power switch internally? If by manage the power switch internally you mean call out to logind via DBus, then yes, I would KDE expect to do the same eventually (provided that they do offer an option for handling the power key). If you are not using GNOME (or more specifically: gnome-settings-daemon), you should be able to set the desired action in /etc/systemd/logind.conf(5), via the HandlePowerKey action. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list Given the thread on SUSE forum[1] it's in the KDE menu / Personnel Settings / Hardware Group / Power Management / Power Profiles. So does the XFCE[2] (I'm not sure if on OpenSUSE, but as general principle). [1] http://forums.opensuse.org/showthread.php/460238-openSUSE-11-4-wakeup-power-button-not-enabled [2] http://forum.xfce.org/viewtopic.php?id=6158 signature.asc Description: This is a digitally signed message part ___ 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 cannot speak for Fedora but ARAIK the packagers don't like bundles as if you have security issue with library X you need to track and find all users instead of patching in one place. In addition you might get symbol collisions if you are not careful. I'm quite opposed to making gsystem a shared library. libgsystem is, to me, 1) a way to put non-portable Linux-specific or gcc-specific stuff, 2) a staging ground for GLib components, for projects that want to get real-world usage before they land in GLib. And I'm sort of not a fan of 2), since it means that there's no motivation to get stuff into GLib (think of all the churn that happened with GSubprocess). On Wed, Feb 5, 2014 at 11:14 AM, Debarshi Ray rishi...@lostca.se wrote: On Wed, Feb 05, 2014 at 03:21:06PM +, Colin Walters wrote: On Wed, Feb 5, 2014 at 10:21 AM, Jasper St. Pierre jstpie...@mecheye.net wrote: What was the issue that happened in Fedora package review? Why doesn't it apply to our copylibs right now, or e.g. libgd? I think no one noticed libgd...review only happens on initial submission, there's no real rigorous ongoing process (I won't comment on the sanity of this model now). Packages using libgd often have 'Provides: bundled(libgd)' in their spec files. Cheers, Debarshi -- Wearing non-prescription glasses and embracing obscurity doesn't necessarily make you a hipster. -- Anonymous ___ 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 signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New developer
On Tue, 2014-01-21 at 19:13 +0530, Suyash Singh wrote: Hello. I am a new developer with some experience in python and linux. I want to be a contributor to GNOME. I wanted to know from where should I start or If I could get some bugs assigned. Anything would be helpful. Hi, The GNOME Love[1] wiki page describes how to get started, including how to find bugs suitable for people unfamiliar with codebase. It might be the best place to start. Best regards [1] https://wiki.gnome.org/GnomeLove signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Potential GNOME IDE
On Sun, 2014-01-05 at 17:55 -0500, Mike wrote: I understand we need a IDE build on top of gtk, and I also want to see that personally. However building a usable IDE is very hard and complex: live parsing and indexing accurately takes significant amount of effort.Especially indexing and parsing complex language like C++ (which I believe a lot of developers would want this IDE to support) . Also, core features such as code completion will be even hard for language like Python. I guess that's why there are users perfer to use ugly IDE like netbeans rather than a good looking Anjuta. Wouldn't libclang solve the 'hard' parts you mentioned for C++? I believe there was a GUADEC talk[1] and there seems to be at least some work for gedit already[2]. (That does not solve the problem for Python, JavaScript etc. of course) [1] https://www.guadec.org/session/clang-llvm-and-gnome/ [2] https://git.gnome.org/browse/gedit-code-assistance signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
On Sun, 2013-08-11 at 14:03 +0200, Stefano Facchini wrote: Il giorno dom, 11/08/2013 alle 06.45 -0400, Jasper St. Pierre ha scritto: So, I wonder if it makes sense to stop generating libgtop and instead just focus on a solid, easily understood codebase. I never really understood why we had a client/daemon split, either; it doesn't seem that we're doing anything too fancy on either side. Is it that we require root for reading some of the files? Should we move to a system DBus service instead? I think that root access is required if we want to implement monitoring of: * per process disk activity (à la iotop) * per process network usage (à la nethogs) That said, a DBus service should be perfectly fine for these features. As a question - what about timeouts? Usually gnome-system-monitor is useful when there is heavy I/O, CPU usage or swapping and in such cases dbus timeouts can and do happen. Moving into more complex area - since application handling on Linux moves to systemd+cgroups would it make sense to get information per cgroup rather then per-process (+ nice user-readable name such as Web or Epiphany rather then /usr/libexec/WebKitPluginProcess)? Possibly something less readable for systems without cgroup-like session handling. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Idea For Semantic Text-Based GTD Application
On Sat, 2013-06-29 at 17:52 +0300, אנטולי קרסנר wrote: Hello everyone, This is a draft of the Quick Start part of a tutorial I'm writing for a data definition language I made. https://gitorious.org/peer-review/peer-review/trees/master The language is currently called Idan. It can be used by anyone, including non-programmers, to define data models (classes, properties, objects) and then define data accordingly, all in simple syntax and plain text. Once the language is ready I'll write the software for it, which can read files and manipulate them. *** Motivation: *** Data models are usually written by the programmer, and a user can't change them. If you want to have a customized system for outlining and todo-list or task dependency hierarchies, either you use plain text or Emacs org-mode. Org-mode is great, but it means you need to use Emacs key combinations. TaskJuggler language exists too, but it's aimed at somewhat technical people who need the tool for serious usage. Idan is simple enough for anyone to use, with Python-like syntax and minimal clutter, and the software will allow connection to RDF, and all kinds of reports and queries, thus allowing to have all the GUI you want, combined with the ability to alter the model by hand and see immediate results. Text formats for task lists already exist, but Idan aims to be a general-purpose model definition language, and has features for out-of-the-box export to databases and external languages such as RDF. Sorry for sounding negative - I've never used org-mode or TaskJuggler and I don't know how to use them. My 'complains' are probably simply unfamiliarity with this class of tools. Unfortunately I fail to see what problems you are trying to solve. Could you provide a scenario where it would solve some problem (what user would be doing from POV of user)? Possibly 2 to show the generality of approach? If you have a few minutes to go over this file and tell me what you think, I'll be thankful. It's s short quick-start tutorial. A primer. https://gitorious.org/peer-review/peer-review/trees/master Sorry for complaining but usually it is much better idea to put the source code then binary file in repository. In that way not only you can get contributions but also vcs are handling text-based formats much better then binaries. To the format: - Do you and if you do how are you trying to internalisation? Should user use Task even if (s)he does not know the English? Or maybe the idan files are paired with gettex translation? - Possibly a small thing but I would change to * or many prefix (for example many Topic topic instead of Topic topic) Best regards Thanks in advance, Anatoly On ג', 2013-06-18 at 05:32 +0300, Luc Pionchon wrote: On 17 June 2013 09:43, אנטולי קרסנר tomback...@gmail.com wrote: Hey Luc and list, I've been planning and designing a language for data modeling and description, somewhat based on concepts borrowed from Python (which I learned in the process). I'm now writing a tutorial, and it looks quite simple and straight-forward, and the language is very simple. Very soon I'll finish the tutorial and I'd like to have it reviewed and hear comments and advice. Is anyone interested? if you publish it somewhere, I'll have a look With a polished language I'll be able to proceed and write a parser and command-line tools, which can serve (with their underlying library) as a base for larger systems and GUI app integration (Gnote, GTG, etc.) regards, Anatoly On ד', 2013-05-29 at 21:10 +0300, Luc Pionchon wrote: Hi Anatoly, if you really get such simple enough language, you certainly will get some users. I see you are planning for more usages, though about TODO apps, did you see todotxt [1] which is basically a text based todo/GTD. They have a relatively simple language [2]. Is it similar to what you are thinking about? [1] http://todotxt.com/ [2] https://github.com/ginatrapani/todo.txt-cli/wiki/The-Todo.txt-Format I think you should go ahead and start to write examples, so people could grasp it, and you will also get a better view of the feasibility. Don't care much about user testing, it's up-side down business thinking. Do something useful, and you'll get some users. go ahead! In any case that is certainly a good learning experience On 29 May 2013 18:02, אנטולי קרסנר tomback...@gmail.com wrote: Hello everyone, I'm an individual not working on any Gnome module. I'll try not to get into much detail (likely to fail on this one), but here's the idea I have: After reading about existing GTD software tools I made the following conclusions: * There are GUI tools * There are plain-text solutions * There are pen-and-paper solutions * There are text-based applications GUI
Re: Switching Between Applications in Gnome 3
On Thu, 2013-05-30 at 18:52 +0300, אנטולי קרסנר wrote: Hello, Hi, I've been using Gnome 3.4.2 for long time. I started using Gnome 3 because I believe in innovation and evolution through trial and error. But I noticed a problematic recurring pattern in my usage of my laptop (I don't carry it anywhere, and it's has a large screen, so it can be considered like a desktop computer). When I work, especially when I program, I have many windows open: Gedit for source code (I know, I know, I should start using an IDE) Devhelp Epiphany window for programming-related pages Epiphany window for other pages (webmail, social network, etc.) Nautilus, with 2-4 several tabs open, maybe also 2 windows Gnome Terminal window, with the working directory being my git repo Gnome Terminal window for compiling short experiment programs I write Evolution Empathy Transmission I'm not sure why you should start using IDE? Different people use different tools (I use both gedit and emacs for programming on Gnome). This is a lot of open windows, so I group them into workspaces. But it doesn't help, I still feel too inefficient sometimes, and I'd like to know how I can improve my desktop worflow and usage. A typical workspace arrangement I use is listed in the bottom of this message. The problems I encounter: 1. When I need to switch between windows in the same workspace, I take the mouse cursor to the corner of the screen, then click on the window I want to see. 2. When I need to switch between windows in different workspaces, I move the mouse cursor to the corner of the window, then move it to the workspace sidebar, click on the one I want, then click on the window I want. I am not a designer but for me the most convenient way is: 1. Ctrl+Alt+Up/Down to switch between workspaces 2. Use always on top + mutters tiling features to have windows I need to be opened at the same time. Say terminal window pinned to corner over documentation (using always on top) or evince and gedit side by side. (I believe 'always on top' is the killer feature of Linux for power users - even my friends using Windows/Mac OS X did agreed that it would be useful add-on). Best regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New GnomeGoal proposal: InstalledTests
On Thu, 2013-04-25 at 10:21 -0400, Colin Walters wrote: See: https://live.gnome.org/GnomeGoals/InstalledTests I'm in the process of transitioning to that page from https://docs.google.com/document/d/1DXgGEKTbC4ed1DFW3Mu-48TpHtq-xdfhDtwoUOWWcHg/edit Comments appreciated; I have prototype branches of gnome-ostree, gnome-desktop-testing, and gjs that implement this, but it's all subject to change. If the test are going to be installed by default it might be reasonable to have a common option (similar to gtk doc) to disable them (if they are not going to be enabled by default - option to enable them) in case user does not need them. Say --enable-install-tests=yes/no. Best regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New GnomeGoal proposal: InstalledTests
On Fri, 2013-04-26 at 12:56 -0400, Colin Walters wrote: On Fri, 2013-04-26 at 18:49 +0200, Emilio Pozuelo Monfort wrote: Hi, On 04/26/2013 05:01 PM, Colin Walters wrote: On Fri, 2013-04-26 at 10:32 -0400, Dan Winship wrote: I want make distcheck to still run all of my tests, to guarantee that everything works correctly when built from a tarball, not just when built from git. That's going to be a high bar to jump; but I suppose it makes sense to have both during the transition and give downstreams time to teach their build systems about revision control. I'm not sure I follow here. Are you implying that you want to stop making tarballs eventually? Yes. https://mail.gnome.org/archives/release-team/2013-April/msg00038.html At least on Gentoo there is partially existing infrastructure but it is not considered superior to tarballs. The collision attack on git is possible, especially when the build is automated[1] and presumably by not closely watching user, while tarballs have their hash distributed by another channel on Gentoo. While for main releases in portage it is not a problem as probably the tarballs would be made by gnome team and uploaded they pose more of a problem for the overlays (sort of additional repos - new packages/unstable versions are usually found there) or bugzilla (another place where people are posting ebuilds). I would presume other source distribution (Nix, AUR in Arch) have similar problems. Additionally currently the Vala programs can be compiled with VALAC=/bin/true and depend entirely on generated sources which are not kept in git (as they are autogenerated during make distcheck). That came handy during the Gnome 3.8 transition as there are several packages that requires older version of Vala, which vapigen is not compatible with gobject-introspection 3.8. Such scheme would not be possible with git tags as the sources wouldn't exist. This would be problem for Vala among others as there would be no way to bootstrap compiler except by another Vala compiler. The same problem is for any files which are meant to not be built (always) by user but are not kept in git - including say autotools files. Requiring each user to run autogen would make the compilation longer (in addition to possible errors due to changes in autoconf/automake). I understand why access people what to restrict access to master.gnome.org but wouldn't replacing shell access with something else be sufficient (or possibly restricting it to scp possibly with special ui for verification without general purpose shell or tarball autogeneration)? Best regards [1] http://joeyh.name/blog/entry/sha-1/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How long should it take to fix a obvious memory leak?
On Thu, 2013-04-04 at 21:20 +0800, Ma Xiaojun wrote: Link: https://bugzilla.gnome.org/show_bug.cgi?id=674092 IIRC pygtk is no longer maintained (as is gtk+ 2) as the newer binding are using gobject-introspection and pygobject 3 which (presumably) don't have this problem. Last commit to it was 2 years ago. Best regards PS. I'm not maintainer of gtk+/pygtk or pygobject and I might misrepresent something. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Log-out behaviour of applications
I've noticed that gedit in GNOME 3.6 prevents the log out (shut down etc.) if it has unsaved data. While it is useful behaviour: - It is not done by any other Gnome application I know - The dialog shown by gedit is unhelpful as to choose an option one needs to cancel the logout, click any option (they don't seem to do anything after cancellation) and then close gedit (choosing to save or to discard changed etc.) I've checked the Gnome HID and it does not mention anything about log out (it looked a bit out of data as even unstable version mentioned gconf). Is there any standard regarding it and if not should we have one (disclaimer: I'm not a designer)? I guess there are several options: - Log out should terminate all application regardless of state. The application themselves should autosave changes (this may be problematic for destructive changes such as photo editing). - Log out should terminate all application regardless of state. The application themselves should autosave changes but not to original file (allowing to undo changes later) - Incorporate buttons into logout dialog. (Do you want to cancel download of GNOME-x.y.z.iso?) - Consider it non-issue - Something else? Best regards ___ 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 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. Best regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Porting GNOME to Wayland
On Thu, 2013-03-21 at 14:17 +0100, Olav Vitters wrote: On Mon, Mar 18, 2013 at 05:31:38PM +, Patrick Welche wrote: More of a Wayland FAQ, but on which OSes does Wayland run? I thought it is not Linux-only, but I am not sure. Anyone know? Quick Google search shows that at least FreeBSD is porting (considering porting?) Wayland to it's architecture. I haven't found anything on NetBSD/OpenBSD. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
On Thu, 2013-02-28 at 09:26 +0100, Dan Winship wrote: 4. It's impossible to create custom Gtk.TreeIter from JS (no constructor), so can't implement a completely custom Gtk.TreeModel. I don't know the details of this particular issue, but if it's not possible to do at all now, then any change to make it more bindable could not possibly break any existing code, so it could happen at any time. IIRC the GtkTreeIter is assumed to not allocate memory. The API and ABI would need to be altered in order to incorporate it as: - 3rd party needs to free GtkTreeIter if it uses one from arbitrary model (possibly not so important) - i.e. there is API change and ABI. - All elements of class struct are already occupied so the size of struct would need to be change - thus changing the the ABI. I looked at the issue around Gtk+ 3.2 when someone asked for non-memory allocating iterators for libgee (I cannot find the request right now but making it bindable would solve this issue as well). Best regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
On Fri, 2013-03-01 at 02:44 +0400, Nikita Churaev wrote:
That's not an issue - you can put even a pointer but the problem is that
you need to pin object. You don't know (automatically without user
intervention) when you can free the resource. At any point GTK might
keep GtkTreeIter alive so data you put inside cannot be freed (or
garbage collected or however you'll call it) and it need's to be always
considered 'alive'. I guess it is possible to workaround the issue by
reverse engineering the Gtk internals but solution would be very
unstable and not remotely elegant.
The problem with GtkTreeIter is that you can't make any function to be
called when iter goes out of scope. Example:
int
foo(void)
{
GtkTreeIter iter;
get_iter_of_something (iter);
do_something_with_iter (iter);
/* iter is no longer needed, C frees its memory
automatically, but we can't make it call a
custom function, as C doesn't have C++'s
destructors, that's why we can't put references
to JavaScript objects into them */
}
However, luckily for us, GtkTreeIter has an integer stamp field that
could be used instead of a direct reference. JavaScript custom tree
models will be slower as they would need to look up items by their
stamps. Example:
_init: function() {
this.parent(...);
this._items = [];
},
getTreeIterOfItem: function(itemStamp)
{
if (this._items[itemStamp] === undefined)
return undefined;
return new Gtk.TreeIter(itemStamp);
},
getItemByTreeIter: function(iter)
{
return this._items[iter.stamp];
}
Yes. That is the problem I've wrote about.
I didn't parsed the sentence models guarantee that an
iterator is valid for as long as the node it refers to is valid (...)
correctly. Arguably this allows to even point to node in one of the
field speeding things a little:
I assume that we don't use list as probably GtkListModel is better in
such case. Sorry if code is incorrect (I don't use JS):
function MyNode() {
this._init();
}
MyNode.prototype = {
_init: function() {
},
next: function() {
}
parent: function() {
}
};
function MyModel() {
this._init();
}
MyModel.prototype = {
_init: function() {
...
},
getTreeIterFromTreePath: function(iter, path) {
var node = doMagic(path);
iter._user_data1 = marshal_as_unowned(node); // Don't pin
}
getNodeFromTreeIter: function(iter) {
return iter._user_data1;
}
root: new MyNode();
};
I'm not sure if marshal_as_unowned exists in GJS now though.
Best regards
signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
On Wed, 2013-02-27 at 23:26 +0400, Nikita Churaev wrote: OK, so it seems that GNOME has a serious aim on making GNOME/JavaScript the preferred platform for new newbies. However, there are some API issues that make Gjs confusing, and bad for PEOPLE. 1. Some functions return useless success boolean: for example [success, contents, etag_out] = GFile.load_contents(). When C g_file_load_contents returns false, it also sets GError, so in Gjs it's either true or the function has thrown exception. The GObject Introspection developers have already introduced (skip) mark for such return values, but they won't add it to existing API to avoid backwards incompatibility. What about adding (skip2) mark that only Gjs will use and replace it to (skip) when GNOME 4 comes? 2. The contents of GFile.load_contents itself is a binary data and yet is returned as a string, it should be returned as a Uint8Array. 3. Gtk.TextBuffer.set_text(text, length) --- length argument is useless, since JavaScript uses UTF-16 and length expects length of UTF-8 string. 4. It's impossible to create custom Gtk.TreeIter from JS (no constructor), so can't implement a completely custom Gtk.TreeModel. 6. Gjs adds a prefix Gjs_ to names of all GObject classes made in Gjs: MyMainWindow becomes Gjs_MyMainWindow and it's pretty confusing when you try to style it with CSS. Is it possible to fix these issues at least in Gjs ASAP without having to wait for GNOME 4, as there are still very few Gjs applications, so we don't have to worry as much about backwards compatibility as in eg. Python. 7. Fixing bug #639908. Not being able to access contact information (among others) from official language (or any other using GIR) is probably suboptimal. Best regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: -Werror considered harmful
Wouldn't it be better to selectively enable the -Wall -Werror rather then selectively disabled it? People compiling the library potentially care less about warning/errors then developers and know less about build system (was it --disable-fatal-warnings? --disable-Werror? etc.) Enabling warnings is as hard as: CFLAGS=-Wall -Werror ./configure make while disabling is more problematic - -w is a workaround but from what I heard it doesn't play nice with autotools and it doesn't help if -Wall -Werror (or equivalent) are appended rather then prepended to CFLAGS. Additional problem is that heuristic of compilers are getting better each version and there is sometimes no clean way of silencing warning - unused result warning for example work up to certain version by assignment to variable - but then compiler change and if the variable itself was not used gcc also complain. I would be for not including -Werror inside configure.ac at all and trust people with commit rights to enable it (either by explicit option or by CFLAGS variable). Possibly building on buildbot with --enable-fatal-warnings if the flag is present would be a good thing (but not CFLAGS=-Wall -Werror as valac produces valid code with warnings). Best regards On Tue, 2013-02-26 at 18:07 +0900, Tristan Van Berkom wrote: Hi Behdad. I'll be the first to agree that -Werror is evil stuff, we even fell into this catch 22 only around a year ago where one group thought it was a good idea to infect our builds with -Werror, while another group thought it was a good idea to add deprecation warnings, ... I'm not even sure we're out of the woods from that tangled mess yet. (and I'll side with the latter, deprecation warnings are a good thing, warnings are a good thing in general). That being said, does glib not use the gnome-common macros, which include the --disable-fatal-warnings configure option ? I've found this configure option to be helpful, not sure if glib still needs it to be added... Cheers, -Tristan On Tue, Feb 26, 2013 at 10:39 AM, Behdad Esfahbod beh...@behdad.org wrote: [I think I'm not on d-d-l, CC is appreciated.] rant Hi, I'm sending this email instead of filing a bug because I think I need to say this as widely as I can: modules adding -Werror (or -Werror=... variants thereof) are harmful Background: A few years ago Javier opened this bug against gnome-common: https://bugzilla.gnome.org/show_bug.cgi?id=608953 which references my blogpost: http://mces.blogspot.ca/2008/12/year-end-cleaning-ie-on-warning-options.html The bug title is Add some more compiler warning options. Something that I thinks is good hygiene. However, in the course of that happening, things like these ended up going in: dnl These compiler flags typically indicate very broken or suspicious dnl code. Some of them such as implicit-function-declaration are dnl just not default because gcc compiles a lot of legacy code. dnl We choose to make this set into explicit errors. base_error_flags= \ -Werror=missing-prototypes \ -Werror=implicit-function-declaration \ -Werror=pointer-arith \ -Werror=init-self \ -Werror=format-security \ -Werror=format=2 \ -Werror=missing-include-dirs \ which then made it into glib as part of bug 687385. Now, can you spot the problem? Hint: the comment above says *typically* indicate very broken. I translate: typically this is fine, in other situations we are breaking people's build, but that's fine. Indeed, the email that went out with the change [1] acknowledged the problem: This gets to the next problem, which is that -Wall includes -Wmaybe-uninitialized and other heuristics like -Wstrict-aliasing. Then combine that with the fact that some people have got it in their head that -Wall -Werror is the Right Thing, what actually ends up happening is your code only compiles on a *particular version* of gcc. That just doesn't work in a distributed project like GNOME, where various bits get reused by different projects and products on different schedules etc. but goes on to conclude: So I think what Dan has is more the Right Thing - make the compiler warnings that you should *never* hit into explicit errors. Interesting. So some omniscient hacker decided that compilers compiling GNOME shall never ever see code that generates a missing-prototypes warning, err, error. Not in the cryptic system headers of whatever weird cross compiler I may be using. I want your crystal ball seized! Here I am, trying to cross-compile glib using mingw32, so I can cross-compile pango, so I can fix a pangowin32 bug, and was stopped getting this: behdad:libcharset 2$ make V=1 /bin/sh ../../libtool --tag=CC --mode=compile i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I../../../glib/libcharset
Re: steam games
On Sat, 2013-02-16 at 11:12 +0100, Tomasz Torcz wrote: On Thu, Feb 14, 2013 at 12:18:55AM +, Alberto Ruiz wrote: I think that it'd be more interesting to engage with Valve to know how the GNOME platform could help steam get a better product. It is an interesting ISV usecase. But GNOME platform is not Steam's target. Valve is targeting Unity, but virtue of making Ubuntu primary platform. GNOME is a niche for them. 1. I haven't contacted Valve directly it looks like they are playing nice with other distros, which are not using Unity. For example they change the license to make it distributable, remove apt-get dependency autoinstall, post non-dpkg installer, give people who explicitly stated they are not using Ubuntu early beta access etc. I haven't experienced any problems with Valve games on Gentoo (I've experienced a few problems with non-Valve games though and I needed to use Google). 2. To at least some extend Unity is based on GNOME (not WM and few other pieces). I don't think that should be argument against trying - in the worse case we simply won't receive reply. Best regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeGoal for 3.8: DesktopFileKeywords
On Thu, 2012-11-15 at 16:48 +0100, Henrique Ferreiro wrote: Not sure matching in other languages, including english, is a good idea. The typical $locale user is searching for a word in his language, likely having no clue that english has a similar looking word with totally different meaning ... the net result is that he will get listed something that's not remotely relevant to what he was looking for without understanding why. You need to go quite some way to figure ok, that work might mean something else in some language I don't know and the system is trying to help me... Users are usually going to install languages they know. And there are many countries with more than one language, in which people may use them interchangeably. I've just checked and at least my university have installed non-English locales (large proportion of students, including myself, are from abroad so it probably make sense in case they wanted to have their own locale etc.). Searching through all locales makes probably no sense as: - You end up doing over 100x more work (CPU and I/O) so you are over 100x slower - You may end up with results user does not understand I'd check for locale. Maybe search similarly named locales as well (for example for en_CA search fr_CA, en_US, en_UK, ...) to cover bi-lingual countries (and people using system in English but not necessary English speakers who don't necessary remember which spelling is 'correct' American/British/... one). Best regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Is File Roller 3.6.0 a broken version?
On Mon, 2012-10-22 at 10:16 +0200, Sebastien Bacher wrote: Le 22/10/2012 10:09, Bastien Nocera a écrit : I've had to close numbers of bugs in Totem, gnome-control-center, and gnome-bluetooth over the past number of years because you barely did updates past the .0 releases. I'm glad you changed that. Just for the record, taking gnome-control-center as an example here is the summary of the versions we ship: https://launchpad.net/ubuntu/+source/gnome-control-center Since 2010 we shipped the updated gnome-control-center stable-versions up to the current one in almost all series (the only exception is Oneiric where we stopped at .2 where there is a .3 update out) I'm glad that you appreciate the efforts ;-) Cheers, Sebastien Bacher Any chances of updating libgee? I don't think I saw any bugs yet caused by it but the Ubuntu versions tend to be much older then current stable in given branch. Best regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make --silent
On Sat, 2012-09-08 at 19:06 +0200, Lanoxx wrote: Hi All, I would like to hear some opinions about why the -s (--silent) option of make is not being used more often in projects? I just updated the configure.ac and Makefile.am files of a project I was working on and I made these two changes: configure.ac: m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES([yes])]) Makefile.am: MAKEFLAGS=-s The make output before I made these changes was 53 lines long (but because of long lines it was wrapped into 115 lines on my screen), with huge blocks of text, that were difficult to understand. Warnings in the code were scrambled in between all these lines, and were difficult to be spotted. Then I added the line in configure.ac and the output reduced to 41 lines which didn't need to be wrapped, but there were a lot of annoying lines like: make[2]: Leaving directory `/home/.../Documents/Code/tilda/m4' And then I added the line in Makefile.am and the output reduced to only 28 (short) lines. In my opinion this has the clear advantage that I can now spot all the warnings and errors in the code very easily, see the example below. I tried to ask in #gtk+ why they are using the SILENT_RULES makro, but are not using the silent make flag, and someone tried to explain to me, that this also silences warnings, but as can be seen below, it does not. I also dont see a real benefit in these make output which only seems to output which folders make is entering. Maybe someone can give me more information about this? Kind regards Lanoxx (...) Sorry if it looks like rant - it's more of confusion. Why people want to have silent output for users? Either: - Person compiling is developer. In this case compiling with -Wextra -O1 -Werror should not be uncommon (and it makes the warnings very visible). In most cases I guess that if they prefer to have silent output they know how to change it. - Person compiling is source distribution user. In such case either everything went all right (in which case he might not even see the log) or not (in those cases very often the problem might be differences between paths etc. so verbose output is useful) - (Person 'compiling' is binary distribution user in which he doesn't compile) - Person compiling uses jhbuild. I have no idea what the needs are but I presume that redirection output to log and just display 'compiling...' etc can be the correct way. In any case - people who care the most would be the one who have the most knowledge to just change it locally (say use -s flag). Best regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Videos from GUADEC/clarification about GNOME on tablets
On Fri, 2012-08-10 at 11:15 +0200, Xan Lopez wrote: On Fri, Aug 10, 2012 at 7:57 AM, Maciej Piechotka uzytkown...@gmail.com wrote: 2. While I understand that mobile is new 'shiny' so far I am sceptical of unified interfaces (and several other things from presentation like pre-installed GNOME on tablet). I will stop here as it would be pointless to complain a lot while admitting that one did not understood presentation. What would be GNOME approach to it[1]? First of all, unless you are complaining about our talk precisely, there is really nothing to complain about. The slides represent Juanjo and mine's opinion about several issues, not GNOME's official stand on anything. Hopefully we won't have to get to the point where we need to prefix everything we say or write with My views are mine only I see. Sorry - as I wrote I hadn't understood the talk as I've been missing the talk. Slides alone can be interpreted in many ways. Cheers, Xan Best regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Videos from GUADEC/clarification about GNOME on tablets
Hi, Unfortunately I was not able to attend GUADEC this year. I tried to catch up with it (BTW the site seems to be down - python cannot open Liberation fonts apparently) - I got to Bright Future of GNOME so far. Unfortunatly for me the slides were on the 'supportive, non-informative' side and I didn't understood much without text. 1. Are there/will there be a videos from GUADEC? 2. While I understand that mobile is new 'shiny' so far I am sceptical of unified interfaces (and several other things from presentation like pre-installed GNOME on tablet). I will stop here as it would be pointless to complain a lot while admitting that one did not understood presentation. What would be GNOME approach to it[1]? Best regards [1] My usecase is traditional n-m windows/workspaces environment which does not play well with tablets (+ both out of convenience and necessity I use a lot of console). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: compiler warnings, -Werror, etc.
On Fri, 2012-07-27 at 21:18 +0200, Philip Withnall wrote: On Fri, 2012-07-27 at 13:24 -0400, Colin Walters wrote: On Fri, 2012-07-27 at 17:28 +0200, Frederic Peters wrote: Colin Walters wrote: For compiler warning defaults, I think something similar what Dan Winship has in libsoup is what we should replicate across more GNOME modules: http://git.gnome.org/browse/libsoup/tree/configure.ac?id=f5902fce98ae0314f0d9ca6e544895548c94a456#n339 It's better than the GNOME_COMPILE_WARNINGS macro in gnome-common right now, and *definitely* better than various modules having -Wall -Werror. Is there some problem in fixing that macro? It would instantly fix dozens of modules (over 50 according to a quick grep). Sure, I'm fine with that myself. Let's see if anyone has objections, if not I'll try a test build and see if anything needs fixing. Not everything uses GNOME_COMPILE_WARNINGS, but that's not a big deal - my main goal here is to in order: Furthermore, is there any reason why modules shouldn't be using GNOME_COMPILE_WARNINGS? It would be great if we could standardise on using it so that we can guarantee that the classes of bugs it detects are highlighted (and perhaps eventually eliminated) in GNOME code. Philip If module is using Vala probably warnings are useless for code generated by the compiler. Maciej ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prototyping navigation in Epiphany
On 08/06/2012 02:45, Bastien Nocera wrote: On Wed, 2012-06-06 at 16:30 -0400, Jeremy Bicha wrote: On 6 June 2012 05:19, Bastien Nocera had...@hadess.net wrote: desktop-devel-list isn't the best place for design discussions though. #gnome-design on IRC, the usability mailing-list, and probably the epiphany mailing-list would be be better places. But the usability mailing list gets very little traffic. I see only 1 email in the past 6 weeks. As has been said many times on this list, unlogged IRC is not an adequate collaboration solution for a large international open source project like GNOME. Except it's high-bandwidth, and with a quicker turn-around. That's also been said many times. IRC tends to be exclusive though. If your working hours does not allow you to be at the meetings then you are excluded from discussion - it's not a case with ml which you can read when you have free time. I am not sure in what TZ the meating take place but I guess lots of potential contributors are excluded from start simply because it takes place say at 4 am in their timezone or at 14 pm when they are at work. PS. That's also was probably said a few times. signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011 (v6)
On 18/10/2011 18:15, Sergey Udaltsov wrote: What's stopping these deprived users from using Gnome 2.X? I don't think there's enough developers interested in keeping the 2.X series alive - it would be a different matter if people were smashing out the features/patches for the 2.X range but as that's not happening I don't see why they don't stay with what works for them? People upgrade distros. They upgrade HW. Would you advise people who love WinXP and hate Vista(ot Win7) stay with WinXP - considering that it has issues with new HW? Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list The metaphore mismatch in two points - the users of GNOME have the power to fork it (I heard even calls to fork GNOME before 3.0) so if sufficient number of developers decides to maintain GNOME 2 it may still live (probably under different name - IANAL and I'm not sure about trademark etc. details). (Whether the discontent have necessary skills is of course different matter). GNOME is also only a part of stack and I don't think GNOME 2 will stop working with, say, kernel 3.6 which would include new drivers etc. the same goes for sane/cups/mesa/... hence it will unlikely have issues with new HW. Regards signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011
On Sun, 2011-07-31 at 19:40 +0300, Zeeshan Ali (Khattak) wrote: On Sun, Jul 31, 2011 at 7:11 PM, Felipe Contreras felipe.contre...@gmail.com wrote: It would be great if some sort of notification would popup directly on user's desktops, this way it can ensured that the maximum amount of people are notified. Assuming user is given the choice at first login if he/she wants to participate, it is indeed a good idea. Would you be providing patches for this? I don't think first login fits well in questions. If the questions are bout Gnome experience then user should have any before answering the questions. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011
On Sun, 2011-07-31 at 19:58 +0300, Felipe Contreras wrote: On Sun, Jul 31, 2011 at 7:49 PM, Maciej Piechotka uzytkown...@gmail.com wrote: On Sun, 2011-07-31 at 19:40 +0300, Zeeshan Ali (Khattak) wrote: On Sun, Jul 31, 2011 at 7:11 PM, Felipe Contreras felipe.contre...@gmail.com wrote: It would be great if some sort of notification would popup directly on user's desktops, this way it can ensured that the maximum amount of people are notified. Assuming user is given the choice at first login if he/she wants to participate, it is indeed a good idea. Would you be providing patches for this? I don't think first login fits well in questions. If the questions are bout Gnome experience then user should have any before answering the questions. What did I do to English grammar in that e-mail? I hope no one who ever taught me this language is subscribed to DDL ML... My idea was to have a GNOME notifications package, or something, that would connect to a site, and then fetch any relevant notifications. The notification in this case would be a link to the online user-survey, and nothing else. Of course, the user should have the option to disable such notifications (perhaps even from the notification itself), but given than they would probably happen only a few times per year, I don't think there such a big hurry to have that option (if needed at all). I think any software which calls homes needs clearly inform user and ask for permission (except if it is in the nature of software like package manager). Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Enabling GConf-over-DBus in GNOME 3.2 jhbuild
On 20/07/2011 19:14, Ross Burton wrote: Hi, So the DBus port of GConf landed recently and there haven't been any totally serious problems reported so far... would anyone object if I changed jhbuild to use --disable-orbit in the GNOME 3.2 suites? If that works out well I may well decide to change the default so you have to --enable-orbit otherwise DBus is the default, but that can be decided later. Ross I've noticed one drawback of dbus over orbit. The dbus session does not carry over into su or sudo while the gconf+orbit did worked. For some programs I wanted to used as root it made a difference (namely meld). While I don't suspect that there are many programs used in su/sudo that uses gconf it might be good to note that the switch may break some setups. Please threat this e-mail as information rather then vote/voice against the move. Regards signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 11:47 +0100, Bastien Nocera wrote: Although I endorse design of the core components, I don't think it has to require the component to exist in gnome-cc. Furthermore, this seems like a fairly arbitrary limitation. Both major non-free desktops permit applications to install control-center. That's because Apple and Microsoft probably wouldn't be very receptive to adding functionality they don't have control over to the control-center. I cannot say for Apple but I've seen drivers and applications that modify Windows Control Panel (i.e. add components). Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Open containing folder for all apps
On 10/05/2011 00:29, Federico Mena Quintero wrote: Hi, all, Per André's request to post features for Gnome 3.2 - here goes. A while ago I blogged about the problem of lack of circulation in our files, and posted a patch for Evince: http://people.gnome.org/~federico/news-2010-08.html#19 In summary, while one can go *down* in the file system hierarchy with Nautilus to open a file, one cannot go *up* from the opened file back into the file system (presumably to explore files that are near the one you had open). Firefox has an Open in file manager command for its downloads, which is pretty useful. I find Evince's Open containing folder command invaluable when I'm organizing PDFs to drag them to a better place. I think all apps that let you open documents or files should let you browse back to the file in the file manager. Akshay Gupta, in the CC for this mail, is my Summer of Code student who will be doing some things around file management, Finding and Reminding for gnome-shell, and such. One of his tasks is to produce patches for a few apps so that they have an Open in file manager command. Nautilus now lets us do this properly: https://bugzilla.gnome.org/show_bug.cgi?id=647204 So, what do you think? The patches for apps should be pretty small, and they really provide much better circulation within your files. Federico Hmm. Maybe a better solution would be to somehow drag'n'drop? Say: - Attach xyz.pdf to e-mail: open xyz.pdf drag the window/contents of window to new mail window - Copy abc.gnumeric to CD - open file in gnumeric, drag'n'drop/contents of window to CD. From what I observed as 'family tech help' is that the users are at least sometimes confused by concept of 'file manager', 'file' or 'folder' (not that I'm using in description any of the word) and their first intuition to do something with file is to open it. I am not UI designer however. Regards PS. I know that DND of window will clash with moving it but maybe there is some smart way of doing it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 3.0: Recommendations wanted for building on LFS 6.8
On Sat, 2011-04-30 at 16:15 -0700, bsquared wrote: On Sat, Apr 30, 2011 at 2:00 PM, Maciej Piechotka uzytkown...@gmail.com wrote: The Gentoo ebuilds may prove useful. GNOME 3 is in overlay. Regards Thanks, I'm not sure what that means. I have no experience with Gentoo's Distribution. Is this a build system, or a package manager? -Brian Overlay is an additional repo. Gentoo is source-based distribution and it uses files called ebuilds to know how to build packages (automated LFS[1] ;) ). They are simply bash scripts although with additional functions (say emake instead of make) to handle special cases. Overlays are simply places where additional files are stored (GNOME's is here: git://git.overlays.gentoo.org/proj/gnome.git). Regards [1] Although with few candies added like use flag handling etc. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Flash plugin disabled in Epiphany 3.0?
On Sun, 2011-05-01 at 20:02 +0300, pec...@gmail.com wrote: I read in changelogs that in 2.91.4 Flash plugin was blacklisted in Epiphany. Is there any info was it unlisted? Or blocking is still in place? I mention this because Flash doesn't work in Fedora 15 beta using Epiphany. Cheers, Peter. Gtk version? % ldd /usr/lib/nsbrowser/plugins/libflashplayer.so| less | grep gtk libgtk-x11-2.0.so.0 = /usr/lib64/libgtk-x11-2.0.so.0 (0x7f1c0f7f) As gtk+ 2 and 3 symbols cannot be in one binary it means that it is not allowed to have flashplayer in epiphany[1]. Regards [1] Possibly it should be possible to run plugins in separate library/load them in some special way to allow it but it is not currently implemented. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
On Wed, 2011-04-20 at 19:12 -0400, Colin Walters wrote: and for 6) I think we need to change this anyways. This leaves reason Speaking as user of epiphany on webkit - it is now terribly broken. Certificate handling is broken since 2009 (1.5 years now) which is security bug as it allows to social engineer users easier (not mention the poison DNS attach etc.). Bug 594856. 4) which I admit is just a feeling. How largely should it affect decisions given both are FLOSS? 7) Embedding Mozilla engine stopped being supported. One thing I'm not totally happy with is the organic growth in API in both seed and gjs. seed for example added an os module with e.g. fork which I think is totally wrong; it's just broken to fork() a GNOME app, since it conflicts with threads, etc. I cannot speak for the gjs/seed as I don't know its inner architecture but not every application Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
On Thu, 2011-04-21 at 10:38 +0200, Maciej Piechotka wrote: One thing I'm not totally happy with is the organic growth in API in both seed and gjs. seed for example added an os module with e.g. fork which I think is totally wrong; it's just broken to fork() a GNOME app, since it conflicts with threads, etc. I cannot speak for the gjs/seed as I don't know its inner architecture but not every application Regards Please ignore last paragraph. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
On Thu, 2011-04-21 at 18:31 +0530, Nirbheek Chauhan wrote: Just a small correction here. On Thu, Apr 21, 2011 at 2:08 PM, Maciej Piechotka uzytkown...@gmail.com wrote: 7) Embedding Mozilla engine stopped being supported. https://lwn.net/Articles/436440/ https://lwn.net/Articles/436461/ = mozjs embedding is still supported I meant of course mozembed not spidermonkey. But it itself is somehow worrisome - at least at the level 'we are more culturally aligned with Mozilla then Apple'. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Archiving 120 Git modules with no commit in 3 or more years
On Tue, 2011-04-05 at 18:07 +0200, Olav Vitters wrote: On Tue, Apr 05, 2011 at 09:33:47AM +0900, Tristan Van Berkom wrote: On Tue, Apr 5, 2011 at 9:17 AM, Olav Vitters o...@vitters.nl wrote: Checking the last commits of the modules on git.gnome.org, I noticed we have 120 modules which haven't received a commit in the last 3 years. I'll archive the modules somewhere this week (modules can easily be moved out of the archive). I've archived modules before when I was really sure that nobody would use it... but 120 is a bit much to check. Posting this list so if anyone has an objection, I'll not archive the git module. The intention is to ensure that http://git.gnome.org/browse/ is readable (old stuff in archive). You might move the old glade module (its now called glade_legacy ?) into the archive too as I did not see it in the list. Just out of curiosity, are they just going to be in another directory ? http://git.gnome.org/archives/browse/ or such ? ATM they're lumped together on the same page. My first priority is archiving stuff. Then to figure out how to show it :) http://git.gnome.org/browse/ already is split into two pages, with a hack to make show the archived and deprecated modules at the bottom. Aiming for: 1. Different URL 2. Hiding the contents of Archived section (IMO deprecated should be shown until they're archived) 3. Decreasing the number of modules shown per page. Currently set at 1000, could decrease it so most archived modules are not on the first page. Prefer option #2. May I ask big the problem is? Splitting into subpages/hiding makes it more difficult to find (I usually search using C-f as it is much faster then determining in which it is in). Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: empathy integration with the desktop
On Tue, 2011-03-29 at 20:58 +0300, Jens Georg wrote: On Tue, 2011-03-29 at 19:53 +0200, Maciej Piechotka wrote: It should be Available or Unavailable why you're unavailable could be a secondary status.. but in general it should be those two statuses. sri Possibly also Invisible - implicit state when screen is locked. Why would that be invisible? How is that different from deliberately not being available? Sorry - I assumed wrongly that they corresponds to status not messages. I.e. they change what other users see. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: empathy integration with the desktop
On Tue, 2011-03-29 at 10:46 -0700, Sriram Ramkrishna wrote: On Tue, Mar 29, 2011 at 2:15 AM, Pierre Benz benz.pie...@gmail.com wrote: On Tue, Mar 29, 2011 at 11:11 AM, Pierre Benz benz.pie...@gmail.com wrote: On Tue, Mar 29, 2011 at 11:01 AM, Johannes Schmid j...@jsschmid.de wrote: Another alternative is to add a offline entry under available/busy in the user menu and start with that active, then autospawn empathy if needed when you switch to available or busy. I think offline is a really bad name as it would indicate to a lot of people that they don't have internet access when they don't switch it to Online or Available. I don't know of a better name but I think having Offline next to the NetworkManager isn't a bright idea. Maybe Hidden? On second thought, Hidden is meaningless. The same with Invisible. Neither of them convey that the user is withholding their online presence from others. It should be Available or Unavailable why you're unavailable could be a secondary status.. but in general it should be those two statuses. sri Possibly also Invisible - implicit state when screen is locked. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.2 ideas and plans
On Tue, 2011-03-22 at 18:00 +0100, Gendre Sebastien wrote: Le mardi 22 mars 2011 à 17:13 +0100, Alexander Larsson a écrit : It would be nice to have some level of integration with web applications in the desktop. For instance, I would like to update my facebook status or tweet easily via the user status menu in the shell. I would also like facebook message notification with the message tray, and facebook chat support. For these points: - I see, in Gnome Planet, that a Gnome-Contact-Center is planned for Gnome 3.2. This app may get status of your contact in Twitter, FaceBook, etc, and notify you by message tray. Hmm. I'm not sure if it best name - probably it should be somehow similar to 'Accounts' tab for Android (I'm not sure how it is dealt with in iOS/Windows Mobile). Possibly it would be better to call it web accounts. Say: - Google account adds IMAP server and calendars to Evolution, GTalk to empathy etc. (depending on which is activated) - Facebook adds chat to empathy, feed to pino/gwibber/... - Dropbox adds place to gvfs - Twitter/identi.ca adds feed to pino/gwibber Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: And about graphics card switch?
On Mon, 2011-02-28 at 23:47 +0100, Gendre Sebastien wrote: Hello everybody. _o/ I have looked at bugzilla and live.gnome.org, but I don't see any plans about managment of 2 graphics card. In some laptop, we have 2 graphics card: A small and a big. Recent Linux kernel supports to ON/OFF each cards. Xorg can't switch without restart, but it's planed on Wayland. So, any plan for Gnome 3.XX about graphics card switch? If not, I proposes a simple implementation. In Power panel of Gnome Control Center, you have the option: Focus on: and can choose between Better battery life and Higher performance. Better battery life use the small graphics card, configure CPU on ondemand and enable laptop_mode in linux kernel. Higher performance use the big graphics card, configure CPU on performance and disable laptop_mode in linux kernel. After option have selected, the computer indicates to the user that he need to logout for apply the change. Regards I may be wrong but from laptop_mode description it less of performance/battery life and more of safety/performance+battery life hence laptop_mode does not suit this choice. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Git: Do not use http to access Git!
On 17/02/2011 13:07, Olav Vitters wrote: On Thu, Feb 17, 2011 at 01:53:12PM +0100, Juan Jesús Ojeda Croissier wrote: I agree. That has happened to me as well. I understand the performance issues, but not to have a http acces to the clones, could be blocker issue for some people. Just wondering, and please see my other reply regarding http.. Why is a http checkout still handy if you cannot commit? Shouldn't everything be much easier when using a distributed vcs like Git? If you don't have write access it doesn't matter for you anyway (you clone to backport patch or to produce patch for bugzilla). Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: IRC channels in gnome development
On 06/02/2011 14:13, Gendre Sebastien wrote: Le samedi 05 février 2011 à 11:43 -0600, Paul Cutler a écrit : Development is not a democracy For a personal project, no. But Gnome is not your personal project, it's a community project. Even if the practice shows that it is good to have dictator (see Linux). PERSONALI appreciate the cleanness of GNOME interface. I like that If there could be one do what I want button we would implement only that one. I don't like obviously removing features I use but I'd like to hear rationale of the decisions - I may agree that the change is justified even if my legitimate use of software is removed or that I use it incorrectly./PERSONAL The light of this, you have a duty of openness to the whole community. That's another matter. Openness and transparency is FLOSS projects are orthogonal. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: IRC channels in gnome development
On 06/02/2011 13:46, Andreas Nilsson wrote: All designs goes in the wiki though and most (if not all) also live in this repo http://gitorious.org/gnome-design As I said - there is difference between the result and process. There have been stated that the design team studied the topic but nowhere what the studies where (name of paper, anything). Maybe using the mailing list would slow down too much but having minutes and setting bot to log the messages probably would not. If there is discussion instead stating that settings kills kitties and small pandas you could just point at research that you based on - say research XYZ says ABC so IJK - instead of saying that there was some research that stated that. If you post what you based on (even only in case of more heated discussion - say 100 comments in beta) then: - Some people will just be impressed, recognize that decision was grounded on something etc. - Some people will read paper, improve their knowledge about UI design and agree with you. - Some people will read paper, improve their knowledge about UI design and disagree with you but using more constructive arguments. - Some people will not read paper and still comment but you still have benefit of not hearing from first 2 groups and having constructive arguments from 3rd. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: IRC channels in gnome development
On 06/02/2011 14:27, Allan Day wrote: Hi, Maciej Piechotka wrote: FLAMEThen show delyourdelinsdesign team/ins work! All I'm hearing is that research have been done and the issue have been taken into consideration during disussion but I DON'T have any references. I cannot see logs of IRC (at least google is not showing them), blogs does not disclose why the decision was made in such way exactly and why the broken workflows are bad. All I'm hearing is that I'm uninformed. The decision presented on blog is presented as final final - not as a strong proposal (even if technically it is the same there are slight differences in PR). I'm not specialist in UI design - but I cannot even get response to information why my workflow is bad and how did you invision it (say - large backups during night)./FLAME Even if you had records of every discussion, you wouldn't get the information you're looking for. Design decisions don't get made committee meeting style, and design involves a lot of specialist background knowledge which doesn't get explicitly referenced. Fact is, we'll probably never be able to give 100% of the rationale behind design decisions. I'm sorry. I had impression that you (as 'defenders') are referring to some specific studies. Basically - it seems that many people have feeling that their needs are being ignored in name of Average Joe and they are asked to leave. And I've repeatedly stated that that isn't the case (and it really isn't). As I said - that is the feeling. I'm not saying that designers don't care but the designers feel you don't care. There are a whole bunch of things in the GNOME 3 designs which are specifically intended for 'advanced' users: * Keyboard-only application launching and switching Technically present in GNOME 2 I believe (at least launching). * Fancy workspaces stuff While present state is suboptimal I agree that the direction seems more then promising. I'm looking forward to it. * Shell extensions * We designed a GNOME tweak utility [2] nearly a year ago Which I cannot find outside mockup in the link. There is Ubuntu tweak but I guess it won't work on non-Ubuntu. PS. To sum up - I think that community thin.ks that decision are made with practically closed doors (not everybody can even observe the discussion due to time constraints) and The only reason it appears that it's happened in the dark is because nobody's been looking. This design could have be seen on the wiki or design repository months ago. Yes. I've started thread to seek the ways to have easier ways to look. I think that posting minutes proposal would be a good way as users could spent 5 minutes a week to follow relevant for them changes) and I don't think that developers would be overwhelmed by it. SIDE NOTE: The log/minutes would have an additional benefit - it happened to me that some person stated that I've agree to do something but I couldn't recall the event and I am sure I haven't agree to do this. From logs I had in my empathy I couldn't find such event. Logging/minutes may have additional benefits for developers (as I might have agreed to do this but I've just forgot). Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: IRC channels in gnome development
On Sun, 2011-02-06 at 22:39 +0100, Andreas Nilsson wrote: I really, really, want the communication channels fixed though. It looked like Maciej wanted to put some time into working on fixing this too, hence why I asked for the help. While I fully understand why the help is expected from me unfortunately neither the knowledge about GNOME infrastructure, wordpress etc. nor real life constraints allow me to do this. I'm really sorry I cannot help. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
IRC channels in gnome development
IRC channels seems to be used in gnome development. It may be just me but I believe that recent power setting crisis show (I contrast them to mailing lists): - Requires presence. Many people cannot afford being on irc 24/7 - both developers, potential developers or just interested users. The houres of the meeting may clash with working hours or other real live constraints. - Not logged. Sometimes during discussion it was said that something was discussed extensively on #gnome-design. That is good however there is no method of figuring out what the arguments where. - Provides less informations. In e-mails I can do smart things like marking read/unread, putting into folders to read/to respond/ignore (or simply - unread: requires action, read: still important, in archive: no action required). Smart clients can even filter out irrelevant threads etc. With IRC I cannot do anything except reading it. There is no side informations and I cannot attach informations. Could there be a recommendation against discussion of important decisions on IRC? While I understand that it may slow down process probably but it would improve developer-user relationships as well as transparency and inclusiveness of process. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: IRC channels in gnome development
On Sat, 2011-02-05 at 11:43 -0600, Paul Cutler wrote: You're asking to change the way things have been done for years - which isn't an argument to not do things that way, but just pointing it ou. However, the GNOME Design team has regular office hours in IRC where everyone is welcome to come and ask questions - I'm not a designer, but I don't know what more you can ask for if IRC is going to be used. I believe that the ask/question is not a problem. The problem is that you cannot easily follow the process. I'm not sure about office hours but: - They probably aren't in best timezone for all. Unfortunatly we have around 26 timezones and there is a chance that a) hours are too long and the relevant designer is not present b) they happen to be between 3 am and 5 am (or 10am and 12am) so not everybody can be there to observe the process. It is possible to stay awake one night to ask specific question but it is harder to do it constantly. - They are not widely know. I tried to googled them without success. They aren't in topic. etc. Development is not a democracy I have never argue to democratise the process. While in politics openness and democracy are considered near synonymous I don't think they necessary are in software development. While it might be a stretch analogy but some people argue in various companies (not every company and it may be argued how good the policy is) to open the discussion/design process to community (I think I heard about Dell, Starbucks and others). Of course it is company who plays the role of beneficial dictator in this model nonetheless the consumers may be proven to be valuable source of feedback and ideas (even if the need to be filtered out). - and for those who are going to do get things done, While it is my opinion I detest IRC even for my own projects for the same reasons that are stated - I prefer working in batch mode instead of online mode as I concentrate on one task. Of course I'm not arguing every developer detest (and apparently GNOME design team likes IRC). discussion via IRC and its immediacy is a powerful tool. I personally think asking IRC not to be used for important (which is relative) decisions is not realistic. Paul While it may be unrealistic it seems that at least some people are surprised that recent UI changes were surprise. Heatedness of debate were not helping but the discussion I've observed (one in blogosphere) was: A: The change . It breaks workflow XYZ. You ***. B: The issue was discussed extensively on IRC. We feel that Average Joe would benefit and workflow XYZ is broken and ***. The unanswered questions: - What exactly was discussed? What were the arguments? - Why workflow XYZ is broken? What should be the workflow be in designers mind?[1] Not using the IRC (or not only IRC) would help as: - Subscription to mailing list is much less consuming then joining IRC channel (low barier to entry - more real live usage and more informations about users workflows and more possibilities to correct them) - There is something persisting to point at. If anyone asks why decision was made you can point them at specific topic/e-mail in archive. Regards [1] Say the change was that there cannot be double enters in text processor and user complains (s)he cannot finish a page to start another the response may be that (s)he should use break page feature. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: IRC channels in gnome development
On 05/02/2011 21:55, Jason D. Clinton wrote: On Sat, Feb 5, 2011 at 13:43, Maciej Piechotka uzytkown...@gmail.com wrote: While it might be a stretch analogy but some people argue in various companies (not every company and it may be argued how good the policy is) to open the discussion/design process to community (I think I heard about Dell, Starbucks and others). Of course it is company who plays the role of beneficial dictator in this model nonetheless the consumers may be proven to be valuable source of feedback and ideas (even if the need to be filtered out). You characterized the situation with the power manager as a crisis crisis was meant to be hyperbolic. and yet, while your description is more than a little hyperbolic, that situation demonstrates that precisely what you are asking for is not productive. There is slight difference between documenting result, documenting rationale and documenting process. There were a total of four blog posts on the topic and approximately 200 comments posted to those. There wasn't any negative feedback on any of those four post's comments that was well researched or particularly informed about all the issues that need to be considered. Even people who tried to offer alternatives didn't seem particularly informed about common use cases or what other operating systems are doing (all research that had previously been done by the design team). There was some legitimate concerns expressed, particularly about why the research shows that AC and on-battery are the same situation, but that was a tiny minority of the feedback and not surprisingly, a large majority of this informed discussion happened on IRC in #gnome-os and #fedora-desktop--not on a mailing list or blog. FLAMEThen show delyourdelinsdesign team/ins work! All I'm hearing is that research have been done and the issue have been taken into consideration during disussion but I DON'T have any references. I cannot see logs of IRC (at least google is not showing them), blogs does not disclose why the decision was made in such way exactly and why the broken workflows are bad. All I'm hearing is that I'm uninformed. The decision presented on blog is presented as final final - not as a strong proposal (even if technically it is the same there are slight differences in PR). I'm not specialist in UI design - but I cannot even get response to information why my workflow is bad and how did you invision it (say - large backups during night)./FLAME Basically - it seems that many people have feeling that their needs are being ignored in name of Average Joe and they are asked to leave. I'm *not* saying that the design team have not done their job - but they seems to fail in communicating their rationale to some power users who feel angry. Sure - I might have done research on topic. I might start reading papers or even ask about them on #gnome-shell. I might have been rational But I guess that the discussion would be much less heated if the references were given - humans are not always rational. I proposed the change to have a shift from 180xYour design *** to even 10xHave you considered XYZ? - Yes - read paper ABC or even just include reference to ABC (give future historians when GNOME will rule the world some sources ;) ). Regards PS. To sum up - I think that community thinks that decision are made with practically closed doors (not everybody can even observe the discussion due to time constraints) and the results are posted as final truths as community is considered too stupid to understand (I'm NOT saying it is true - I'm saying it is the FEELING). It may be even more PR problem then technical one but I believe it is important one anyway. Contrast it with even Linux kernel where Linus is benevolent dictator and while some decisions may be considered controversial there is some discussion in public and loggable media. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: IRC channels in gnome development
On Sun, 2011-02-06 at 02:52 +0100, Olav Vitters wrote: On Sat, Feb 05, 2011 at 05:25:08PM +, Maciej Piechotka wrote: Could there be a recommendation against discussion of important decisions on IRC? While I understand that it may slow down process probably but it would improve developer-user relationships as well as transparency and inclusiveness of process. We hold our release-team meetings on IRC and prefer to keep them on IRC. However, we make minutes and send them to the mailing list. Great. However: - Which mailing list? There is no gnome-design list listed and on gnome wiki there is only reference to gnome-shell mailing list. I am however nearly sure it is neither d-d-l nor g-s. - Why noone in discussion pointed out the minutes with arguments to complainers? Further, we discuss beforehand when a meeting will be held. Suggest that you propose such things. I'm sorry but English is my second language and I'm afraid I haven't understood last sentence. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: IRC channels in gnome development
On Sun, 2011-02-06 at 03:13 +0100, Olav Vitters wrote: On Sun, Feb 06, 2011 at 02:02:10AM +, Maciej Piechotka wrote: On Sun, 2011-02-06 at 02:52 +0100, Olav Vitters wrote: On Sat, Feb 05, 2011 at 05:25:08PM +, Maciej Piechotka wrote: Could there be a recommendation against discussion of important decisions on IRC? While I understand that it may slow down process probably but it would improve developer-user relationships as well as transparency and inclusiveness of process. We hold our release-team meetings on IRC and prefer to keep them on IRC. However, we make minutes and send them to the mailing list. Great. However: - Which mailing list? There is no gnome-design list listed and on gnome wiki there is only reference to gnome-shell mailing list. I am however nearly sure it is neither d-d-l nor g-s. release-team mailing list. Depending on the topic, devel-announce-list is informed. Ups. Sorry - I thought you are from design team. Further, we discuss beforehand when a meeting will be held. Suggest that you propose such things. I'm sorry but English is my second language and I'm afraid I haven't understood last sentence. We (release team) make various efforts to keep everyone informed. By minutes and discussing beforehand when we meet. Further, we send to devel-announce-list when needed. If one team (#gnome-design) doesn't follow that, you can do various things to actually make things better. A few changes/additions to the way they work to ensure the process is workable for everyone. This e.g. by minutes, agreeing on meeting times, etc. Sounds sensible. As it was stated that they discussed it extensively in such minutes there would be more information about topic hence something to refer to. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Cantarell? (Was: Re: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement))
On Wed, 2011-01-12 at 11:53 +, Allan Day wrote: Andrew Cowie wrote: On Mon, 2011-01-10 at 12:33 -0500, Owen Taylor wrote: * The default font will be changing to Cantarell Cantarell? If Cantarell is this, http://abattis.org/cantarell/ which says As my very first typeface design... designed for on-screen reading; in particular, reading web pages on an HTC Dream mobile phone ... font file currently contains 391 glyphs then at first glance it seems an odd choice. DejaVu serves us well with outstanding coverage across the Unicode space and one of the only fonts with complimentary Serif, Sans, and Sans Mono families. Do we need to replace it? It's not a question of coverage; it's about style (though we need to use fonts that have good coverage, of course). The visual style that has been developed for GNOME 3 is one that aspires to be subtle and refined. Stylistically, Cantarell accords with that in a way that DejaVu does not. Another aim for GNOME 3 is to ensure that the new desktop is visually distinctive. Cantarell is a better choice than DejaVu here, too. I'm really excited that we're using this new font for GNOME 3; it has a really nice design and will give the new desktop an extra bit of sophistication. Allan According to my fast check (which may be wrong) it seems that it does not cover still used Greek alphabet (tech people aside it is still used in greek language). It does not cover Cyrilic (used among others in Russian) and Chinese and Hindi (I copy the names of national anthem from wikipedia) as well. That alone would make early 40% of world's population according to Wikipedia (sure - probably most Hindi users are bilingual but they would still want to see their documents' titles - fonts are even more important then translation)[1]. I don't think that using Latin alphabet (+ few extentions) + few others (such as Arabic) should be requirement for GNOME 3.0. While it may not be a problem for webpage (it is usually in one language controlled by creator) it is for desktop where you will find large variety of languages. Sure - desktop font probably does not require ⊕ or ⊛ (although it would be nice) but I don't think that cutting large portion of users justify subtle and refined style. Regards [1] Ok. I've just added population of countries - but not fully supporting displaying characters of 2 biggest countries in the world would be rather bad starting from user experience through message sent by Gnome ending on the marketing. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement)
On Mon, 2011-01-10 at 19:03 +0100, Josselin Mouette wrote: Le lundi 10 janvier 2011 à 12:33 -0500, Owen Taylor a écrit : * UI will be added for displaying information about fallback mode and forcing fallback mode when the system seems capable of doing a full composited desktop. (This is my biggest area of concern going into GNOME 3.0 - not having the final design or much code for this.) Is it really necessary? wouldn’t it be simpler to let the user choose in GDM, provided the packages necessary for fallback mode are installed? I'd say yes - if the login will not work out-of-box [new] user will say that Linux is not working and switch back to Windows. Unfortunately from user perspective Windows works out of box (read someone have installed it and configured but user haven't seen it) and Linux requires configuration and is hard. Even more advanced user wouldn't want to track what is wrong with setup that broke after update. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: Moving d-d-l to moderated until after GNOME 3 release
On Fri, 2011-01-07 at 18:37 +0100, Dave Neary wrote: In particular, note the following mailing lists: * gnome-annouce-list - all software announcements * gnome-list - discussions/questions about how to use GNOME Does gnome-list cover the design process of user experience? * foundation-list - discussions relating to the GNOME foundation * nautilus-list - Nautilus development To that list I would add Bugzilla and gnomesupport.org It would be nice to have 'what channel should I choose' page - it might increase signal-to-noise ratio for lists. For example an idea about gnome-shell evolution integration should go to: - gnome-shell/evolution list crossposting - gnome-devel-list (it's about Gnome overall user experience) - gnome-list - bugzilla (which product?) - irc (which channel?) - ... Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME community survey
On Fri, 2011-01-07 at 13:45 -0800, Germán Póo-Caamaño wrote: Since people from Others section also got the invitation (like me), I wonder, whether the results of the questions regarding making GNOME better and the effort taken into GNOME may become a bit inapropriate, as those aren't actually doing that (their software is not shipped with GNOME). Or does GNOME in this case mean GNOME + software meant for GNOME-using people? Just wondering. I do not know what do you mean by Others, but if you got an email is because you have contributed with GNOME (considering the software under gnome.org). By others he probably mean components not in desktop/platform etc. sets (marked as Others in bugzilla, git etc.) and therefore not part of GNOME (like banshee, vala, libgee etc.) Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
On Tue, 2011-01-04 at 18:37 +0100, Gendre Sebastien wrote: - Gnome Shell are no modular. It's need to separate the Shell from the window manager. Each window have to be managed by the window manager and Shell menu and panels by the Shell. With actually Gnome Shell, the non-modularity imposes the Shell with the Window manager and vice versa. As far as I understand the gnome-shell **is** window manager. For example in overview mode it is shell which allows me to move windows from desktop to desktop etc. While I'm not necessary fun of the current situation I don't think it is possible and not due to implementation choice. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
On Tue, 2011-01-04 at 20:37 +0100, Wouter Bolsterlee wrote: Emmanuele Bassi schreef op di 04-01-2011 om 00:14 [+]: Still being able to type weird characters I count three ways of doing that: • Ctrl + Shift + U + hexadecimal. • Compose key. • Character Map Let me add convenient for frequent use to my original phrasing and my point still holds. — Wouter I believe that compose key gives such option. Say Compose+g+a can be configured to give alpha. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
On Tue, 2011-01-04 at 20:58 +0100, Wouter Bolsterlee wrote: Maciej Piechotka schreef op di 04-01-2011 om 20:43 [+0100]: On Tue, 2011-01-04 at 20:37 +0100, Wouter Bolsterlee wrote: Let me add convenient for frequent use to my original phrasing and my point still holds. I believe that compose key gives such option. Say Compose+g+a can be configured to give alpha. Oh yes, it's very convenient for me, and also for others who know about it and explicitly enabled it in their keyboard configuration (hidden in a dozen other options behind 3 level dialog structure). My point was that there should be a more easily discoverable and user-friendly way, i.e. pick from a visual list versus remember sequences hidden behind an invisible magic key. The character map applet provides exactly this, which is why I am arguing it is essential, especially for many non-English speakers. To be honest - I *did* try to add modification of keyboard feature request[1]. Personally I'd like to have an advanced, easy to use, integrated with desktop keyboard editor. [1] https://bugzilla.gnome.org/show_bug.cgi?id=599200 (FYI: Dutch requires some accented letters to be able to write correctly, but those characters are not on our keyboards since all computers have a generic American English keyboard.) (FYI. So do Polish, the exact letters are ąćęń󟿥ĆĘŃÓŹŻ. I managed to tweak keyboard by xmodmap although you may also choose to switch keyboard layout - I don't since I normally use UK keyboard which have few keys in different places and I don't like if @ key is in different place). signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
On Mon, 2011-01-03 at 15:09 -0800, Sriram Ramkrishna wrote: 2011/1/3 Mario Blättermann mari...@gnome.org Am Montag, den 03.01.2011, 13:37 -0500 schrieb Owen Taylor: There will also be some people that want to use gnome-panel because they aren't ready to change. While we want to encourage people who have capable hardware to update and use the new experience, there are multiple advantages to accommodating such users in fallback mode as well rather than telling them to use GNOME 2. Im afraid we will have a lot of more people who use the fallback mode or classic mode than the new desktop shell. Keep in mind, a Linux or BSD distribution will be installed on older hardware in many cases, because the newest Windows doesn't run properly anymore. On my five years old IBM Thinkpad T41 with ATI Radeon Mobility 7500 I cannot use gnome-shell. Only black windows... On the other hand, Compiz with most of its nice features works fine. That's why we *must* provide an appropriate clutter-less fallback mode for the GNOME 3 lifecycle (yes, for the whole cycle!). What about to have a gnome-shell with a fallback mode which works (with function constraints) with the good old metacity or other window managers? And keeping gnome-applets as gnome-shell-applets? Otherwise, we will get rid of a lot of users. Gosh, so you believe that the majority of the Linux desktop market consists of old platforms? Gnome-shell should work on any machine that is about 5 years old. After that even things like flash and web browsers are going to be dog slow. You simply would not use the primary application, the Internet in any appreciable fashion. Hopefully, said users are not some old grey beard still running around using gopher, and lynx to browse the web. :-) I'm not sure what's your point is - could you clarify this paragraph? Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Re: gnome-panel gnome-applets?
On Tue, 2010-12-28 at 15:19 -0800, Sriram Ramkrishna wrote: It will be important to get people writing extensions before the release happens i think. (sorry went into marketing mode...!) I take the liberty of saying that as person who tried to write an extension (some time ago): - Lack of basic documentation. Reverse engineering C/JavaScript to write an extension (for example - how to use St) is very hard. - Lack of basic tutorials. There no Hello World tutorial, video or anything (at least linked from page). [I distinguish between step-by-step tutorial and detailed documentation] - High overhead of code - if I remember correctly adding button requires adding to 2 files (CSS and JS) - where button should be put/how it behaves and how does it look like. Other technologies (gtk+ + gtkbuilder, html+css+js) allows to work on the scaffolding first and then work on details. Possibly 'sane' defaults and primitives would help. - Lack of sandboxing. I'm not quite sure if and how it can be done but last time error crashed whole shell. Since JavaScript gives dellittle/delinsno/ins compile-time checks and errors do happen it would be helpful. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Re: gnome-panel gnome-applets?
On Wed, 2010-12-29 at 13:41 -0800, Sriram Ramkrishna wrote: On Wed, Dec 29, 2010 at 4:08 AM, Maciej Piechotka uzytkown...@gmail.com wrote: On Tue, 2010-12-28 at 15:19 -0800, Sriram Ramkrishna wrote: It will be important to get people writing extensions before the release happens i think. (sorry went into marketing mode...!) I take the liberty of saying that as person who tried to write an extension (some time ago): - Lack of basic documentation. Reverse engineering C/JavaScript to write an extension (for example - how to use St) is very hard. The Gnome shell guys only have limited resources. Owen and Jon are more than happy to help if someone wants to volunteer to do them. But their focus is on getting shell feature complete for the first release. Having done some of the work, it would be great to document what you've done thus far and then consult Jon and Owen on the limitations like reverse engineering. I know for a fact that a lot of components still haven't gotten the inspection work on it and they are looking for volunteers for that as well. Some are pretty easy others take some work. I'm sorry if I sound accusing of something. I wanted to point out what I found to be biggest limitation of writing extensions to gnome-shell. I gave up very quickly due to time limitations - I had done none work at all (except displaying label Hello World on LHS of screen). At this moment I have way more projects then time not mentioning the 'real life obligations'. Probably many of the documentation would be shared among 'core' shell and the extensions so it might help getting volunteers as well. - Lack of sandboxing. I'm not quite sure if and how it can be done but last time error crashed whole shell. Since JavaScript gives dellittle/delinsno/ins compile-time checks and errors do happen it would be helpful. Yeah, we probably want to move this over as well. It doesn't particularly address the current topic in regards to fallback to Gnome classic. sri Sorry for posting it but I wanted to point out the problems person unfamiliar with toolkit/platform finds on initial stages of extension development which seems to be crucial to 'get people writing extensions before the release'. Regards PS. While I have my concerns regarding gnome-shell I find it easier to use after some time then classical Gnome - so I'm sorry if I'm over-critical. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-spidermonkey?
On Sat, 2010-12-11 at 08:33 +0100, Frederic Crozat wrote: 2010/12/11 Maciej Piechotka uzytkown...@gmail.com: On Fri, 2010-12-10 at 13:16 -0500, Colin Walters wrote: Basically, I want us to be decoupled from this; there are conceptually actually 4 layers. NSPR - spidermonkey - xulrunner - firefox Where - is depends on. Right now at least Fedora ships like: NSPR - (spidermonkey xulrunner firefox) Where () is tightly coupled, meaning that gjs and gnome-shell are tightly coupled to firefox. Having a separate xulrunner as a project hasn't really worked - it's a *huge*, enormous codebase. Spidermonkey on the other hand has always nominally supported being built seprately; it has its own configure script, etc. Probably better way would be to work on parallel installation of xulrunner and/or spidermonkey then forking. I.e. if needed there should be possible to install, for example, xulrunner 2.0 and xulrunner 2.1 at the same time. This is already possible for xulrunner in most distributions. Then probably the problem is Fedora itself then coupling. Since otherwise the gnome-shell/gjs are coupled to particular branch of xulrunner if I understand correctly. I guess update xulrunner 1.9.x - xulrunner 1.9.(x+1) does not require code changes so the problem can be derefered to distributions (updates, updating fx/gjs/gnome-shell when ABI changes for example due to inlining etc.). Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-spidermonkey?
On Fri, 2010-12-10 at 13:16 -0500, Colin Walters wrote: Basically, I want us to be decoupled from this; there are conceptually actually 4 layers. NSPR - spidermonkey - xulrunner - firefox Where - is depends on. Right now at least Fedora ships like: NSPR - (spidermonkey xulrunner firefox) Where () is tightly coupled, meaning that gjs and gnome-shell are tightly coupled to firefox. Having a separate xulrunner as a project hasn't really worked - it's a *huge*, enormous codebase. Spidermonkey on the other hand has always nominally supported being built seprately; it has its own configure script, etc. Probably better way would be to work on parallel installation of xulrunner and/or spidermonkey then forking. I.e. if needed there should be possible to install, for example, xulrunner 2.0 and xulrunner 2.1 at the same time. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (not) proposing Snowy for GNOME 3.0
On Fri, 2010-10-22 at 12:27 +0200, Rodrigo Moya wrote: On Thu, 2010-10-21 at 21:35 -0700, Sandy Armstrong wrote: == GNOME Web Platform == There is no GNOME web platform. There are no new libraries being proposed for use by all GNOME web modules. It feels way too early to try to make those sorts of decisions. We need another module or two before we discover what can and should be shared. I will say that even if we end up with an Online Desktopish goal, we should not strive for one big monster web app.I think it makes sense to focus on smaller, single-purpose web apps with sensible integration points. For example, we could have a Mugshot-like identity app for Teh Social, and have it aggregate info from apps like Snowy. We could tie apps together with existing standards like OpenID and OAuth. We could come up with conventions for building RESTful APIs, standardize on JSON, etc etc. We could build standard GTK+ widgets for authenticating with GNOME web services. Whatever makes sense to make integration between the GNOME desktop and the GNOME web easy on developers and users. yes, maybe it would make sense to have a generic sync API, so that the same API and server could be used for syncing notes, contacts, calendar events, etc. I don't think that would make a monster app, if it's just a syncing server implementing a single API, wouldn't it? I'm not sure but there was some time ago part of implementation in CouchDB (there is evolution-couchdb etc.). At least the replication could be done by standard tool (like couchdb) and the web GUI will contact with the same standard backend. It may or may not be couchdb but couchdb implementations on client side already exists. So basicly it would be reimplementation of Ubuntu One on some license (AGPL?). Regatds signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: G/tkApplication
On Tue, 2010-10-19 at 10:01 +0100, Richard Hughes wrote: On 19 October 2010 00:44, Ryan Lortie de...@desrt.ca wrote: The upshot, though, is probably that quite some application that were making use of the old GApplication have stopped working. So... what versions of gtk+ and glib should GNOME 2.91.1 tarballs be targeted against? Can I just skip 2.91.1 tarballs and just ask people to compile everything from git master? Please don't do that (I'm asking as user). I stopped using 2.9x GNOME because I was tired of trying to check what revision of which packages works with what revision of gtk+/gobject-introspection. Compile everything from git may require users to downgrade packages from time to time as, for example, gedit requires gtk+ 2.90.6 while webkit requires 2.90.6 (historical example). Unless there will be some 'stable' releases of GNOME 2.9x (i.e. those which at least build against each other work for some wide definition of work) I am certain that I won't bother with trying it - and I would be surprised if many other would. Richard. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome 2.32, Gnome 3.0 gtk 2.90.6 from alpha (pre-alpha?) user point of view
I am sorry if it is not correct mailing list however I didn't found better for describing problems with testing Gnome 2.90 due to release process. I tried for some time keep parallel gtk+ 2.x and 3.x install testing new packages with gtk+ 3.0. However it became increasingly hard: - Sometimes packages started to be depend upon non-released version of packages. Sometimes even unwritten. - gtk+ 2.90.6 removed a lot of API/ABI and introduced new one. I understand that it is one of GNOME goals[1] - however it created wide gap between migrated and not yet migrated packages. Additionally some packages required gtk+ 2.90.6 even when it was not needed[2] or require it without marking it in configure.ac (again understandable).[3] - at least one crash bug was commented as of low priority as the crash was in GdkGC on gtk+ 2.0 build [2.31.x] as [package] master is on GTK+ 3, so this is very likely to be obsolete.[4] which at that point I had installed because of connection of other package which in gtk+ 3.0 version depended on unwritten version of package (now - on unreleased version) While I understand the problems concerning move from 2.x to 3.x I fill that the usage of 3.0 is increasingly harder. However the alpha/beta users are IMHO needed - I can have very different environment then developer and I may use it in different way. For example I may use multi-byte UTF-8 characters and encounter problems in code where number of chars and number of bytes is treated as equal (real live example). I don't want to direct this at anyone - I feel that everyone is acting in rational way trying to create the best software he or she can. However I have feeling that the testing with those releases are harder than usual and creates the above situations. KDE 4.0-like situation would certainly be far from ideal. Regards [1] http://live.gnome.org/GnomeGoals/GDKtoCairo [2] As developer stated he tests it on GTK+ live, which is understandable. [3] On the other hand I understand that does not build is fixed earlier then uses deprecated symbols [4] To be honest - stack trace was damaged for some reasons (I have debug symbols for all libraries and programs on system) which did contribute to closing bug. However closing was before I replied that stack trace was damaged despite presence of debugging symbols (which can be seen as pointers on stack trace are too low to be from memory-mapped ELF file IMHO) signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.91 tarballs?
On Mon, 2010-08-09 at 15:39 +0100, Richard Hughes wrote: On 9 August 2010 14:15, Vincent Untz vu...@gnome.org wrote: You can release 2.90.x (not sure why you'd want 2.91 before 2.90 ;-)). Some modules already have such versions. 90 is an even number, and thus 'stable', surely? Richard. I thought x.9/x.90/x.900 are beta releases before (x+1).0. See gtk+ 2.90.4. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 in March 2011
On 28/07/10 15:48, Frederic Peters wrote: Hello all, A few release team members talked with various people during the first few days at GUADEC to get a better feeling of where we stand on our road to GNOME 3.0. We held a meeting later and decided that GNOME 3.0 should be postponed to March 2011 to make sure this release will have the high quality we all expect. Our community wants to be proud of what we will release as 3.0, and moreover, we don't want to disappoint our users who are excited about our goals for GNOME 3.0. We will still release a stable version of GNOME in September, and we'll call it 2.32. We encourage maintainers to add a configure flag to easily make their modules use GTK+ 2 and GTK+ 3, or to create a gnome-2-32 branch where the 2.32 work will be done. Thanks to the hard work the community has been doing in the last few months, we have achieved a lot for GNOME 3 and we therefore want to also release a GNOME 3 Beta in September. This will clearly send a signal that we want people to start playing with GNOME 3, and this will help build even more momentum before the release. Finally, it's important that everybody keeps focusing on making the GNOME 3 vision a reality: the additional time that we have until March 2010 should be used carefully and we encourage maintainers to target achievable goals during this new cycle. Cheers, Frederic Sorry I'm resurrecting the thread. I used part-GTK+ 3.0 desktop and I noticed that version no longer follows the migration (i.e. 2.31.5 of package uses GTK+ 3.0 but 2.31.6 uses GTK+ 2.0). May I propose that: Future 2.31.x/2.32.x uses GTK+ 2.0 Future 2.9x.x uses GTK+ 3.0 (especially if released along the 2.31.x/2.32.x) Regards PS. I'm sorry if similar proposal had passed - I haven't noticed it. signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump min vala version to 0.9.3
On 15/07/10 01:18, Zeeshan Ali (Khattak) wrote: Hi, The new vala release contains some improvements to glib API that breaks rygel's build so I would like to use vala 0.9.3 in the next release. libgee 0.5.2 will and current master do require that version. Regards signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 09/07/10 16:37, Christian Fredrik Kalager Schaller wrote: I would strongly prefer glib to not change its license, we are keeping the lgplv2.1 in GStreamer, partly because a lot of people making products with GStreamer prefer it over lgplv3. If glib switched under us it would make our license stability a bit of a joke. If someone wants to use glib under the lgpl3 they can do so now with the current license, if upstream changes however, people can not keep using it under the lgplv2.1 without forking. Christian Not quite true. You can link LGPL 2.1 project with LGPL 3.0 library according to FSF. IANAL but LGPL is not viral license and you can link anything with it. Regards -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAwAGBQJMNzfkAAoJEJIdee2Vr4aPDdwQAIuZY3W/tob22Ll59EGXAJkD eWO0lExXFf2Ji6/BSrH2E6IQD1UJgrLaVgZHlw4FoHhvpIvHqNF3VKTLMvQpjZq+ Y60Ee+XW+zCofTpAe0BpXMVg1bani/FLT94LNbMaaphvV95yCcKE3aPQBv58Dv1G Lwk3zuPaAQfeIXCQHXP0Vsjm/YqpQLjAnaiNkQ9j6fM2vWBYltrYW+2BCCjniwra apOnDhYjQPqXu6hO0AbtDJylsRSj+RYhKa2lgZ39CaeAmlTvIGkB/MniHC23MVXJ K87vh8WD8Tzy7uE9p7jjSC7xcBN2qDhhMRElUe/TF6RuB22yfU4cGa2hisHsR2j4 nUfswKsG18BvXpcwtCk+ftXvHLkijxd5QmJDEii/cgFqqbgHNLp4fqkZGfmuIwSc pNdsYGIwj5oacNT5aPjuppVNu9U3QdZ+3Sf9eMNzzPU6I+EbARmkwm8XMdy0VM46 AJjelhMT3Hzfk8F9YxkhRaCgluS7cdzxddfE/fV0RU/4ER/nxiQnl+MtdLmVHIGQ 3cW4ww/u3r1evb5s8cAy220gVv9BicYECxJOUXgm4f5Wa36HC+gkyf5qBdKPKQYk rNolzDYmP4AhWDWlFpt2ltkSRYHSCaGj1svdVTCIuTux4sr+klUx18S/ERoxwOqw SbqlSZXXU0Ar3rflGgOe =apOq -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 06/07/10 15:12, j...@jsschmid.de wrote: Hi! hi Vincent, On Tue, 2010-07-06 at 09:26 +0200, Vincent Untz wrote: Do you feel okay with the idea of allowing proprietary apps to use our platform but not GPLv2 apps? In short, yes. Anybody who has an application that is GPLv2-only and has accepted enough contributions that it has become an unreasonable proposition to relicense has made a significant mistake. I don't want to punish them or anything, but they are the ones who picked a licence that prevents them from linking against just about anything. Well, while I guess all my modules are LGPL/GPLv2+ would that still prevent me from linking against LGPLv3 things if I don't convert them to GPLv3? IANAL but LGPLv2+ means that you can use later license like LGPLv3 which is compatible with GPLv3. Also, am I right that GPLv2+ means that I have GPLv2 in the COPYING but every file include the or (at your option) any later version clause? IIRC it is included by default in FSF text of license. Regards -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAwAGBQJMMzLoAAoJEJIdee2Vr4aPJO8QAJ7EgO7WzufdqSwJkUN6fk0m MzLK380xhTY8a4KpqJpMxVz5UbZToRMSt3fOTMMoJmEAIv7fTH8+heWQoE7FiqwJ e3mxCPAapjlkP+Vcd6EclEuULgPegJFZ9IEQNegluRhdstkSdiCxDM3KhWV0/MO7 EhKcl43GdLO23l4OFUnOXbW5xj/EIZsdzuS2BwWAGn4z9ldMqVe0VgUwHTvx0htv +oxGJvPBn/X9PgfO23EdTftKOhVqIbk4DjBVpNm/mtoXKU5WYynIEMANNwOvxoKp QUjNS/GpccR4uyQhN67LSLixai6Q9OaQlKoMywqp1Yi9WQz9jmPRehxjEYLQTko9 1CrlTl5PI4LYJv8XWCa8hGaPPF+pjlGNcab0B/7E8BpMdLO3BLc5AncVECl+hpgI CZPwVo53Wd+UR0cwXQ6XkPTA9MAexTWUFe4CbS2iwqmqmokPlkzLtDR98Boqf6A0 BMUipoODInchKHnjfw8DdOn+/LYtnOZJWC7e3bGTBX7AnfSgJdMl6OybfpDqzfww +kKckLWN7jTnYS4E28uVEEJgB7k94UuNBsqV/v6HHiuEDtlqHUqQY9BsAM9yWKF7 AP8XdFymd6HonLNZ40ePD4axPgCnxZNETriIApOMffb1oBe+pN7lBmCaxURF9TMs BQ4O36bJfzzOVRZgf/qw =suIv -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Converting libraries and plugins to use gtk3
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 11/06/10 14:28, Alexander Larsson wrote: Any library that links to gtk+, gdk or gdk-pixbuf, that switches to gtk3 will need to have the new version be separate from and parallel installable with the old version. If this is not done then distributions can not ship applications still using gtk2 linking to the older version of the library, as this change is binary incompatible (and since you can't mix gtk2 and gtk3 in the same app). I'm sorry but may I ask for interpretation of the following text? I interpret that separate packages (as well as Gentoo developers responsible for GNOME packages) that it applies at package-level. However evolution-data-server developer(s)[1] thinks otherwise and believe it is sufficient if the only libraries linking to gtk+-3.0 (like libedataserverui-3.0.so) need the bumping and rest of packages bundled do not. It creates making a package harder, especially in source based distribution as it requires splitting package by hand and to resolve incompatibles between versions. Additionally one file (/usr/lib64/evolution-data-server-1.2/extensions/libecalbackendweather.so) have 2.x version (1.2) while linking to libgtk+-x11-3.0.so.0. Could anyone clarify (and reopen if appropriate) bug 623462[1]? Regards [1] https://bugzilla.gnome.org/show_bug.cgi?id=623463 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAwAGBQJMMg2IAAoJEJIdee2Vr4aP0CUP/0aP5KRVAjHH15Oh83M1A1vY BDWgvx2WjaWPXD5pth5s45yQmYq29YfBPSypMj8GGJ57y0Rz5kFLZtaA31Gli11s bOswBeoUS1cDIpLhACg95xhtAt7afFVt/F7BQ8xp2og6hP3p7KPUcgSvmRZY1B3y IBc0xX/7PMuvHCrM2zdjFwQcszoR1tkTMQqqTeF2RA+aVLry7f1y7VasnyzrqtvM rpt5aQxX5/fzlFO4VQeTa6qNYCajMAFyzjiknM6K1GL8B8CIoJ0h0JzhxfUH3q+V gCFRa17SKeuRoNZKMk+8ink4vg8KID+Ouckya7gNQH6Y6PZw3h+DBio6YbY3cpR5 fIMS4QIQkEK7fpFO75T9duPdPvykjVVkLI+4omBIdcRgugifs0g6gczE3Ai4lqCY gNr+IXau7MIclAA6Q1jJu5DEsGfEsx5p95BGWwNaFYP7oH/OorVQB5g2W0fL+8cP StaOiknxQ1OthaTdq5C/Cc7jtNIYdA/C+hfYI/oMnfsCFKtgLMsB2lEvHL9F005p wfEIS2Xgc5zsrvVIkFLh4IrQ1GjePfitqJfC4jsaWnJmFKp0ba2kb/wEUfruoqLa N3MyEPKunOXeWZzpKH5b8iQ5P2xJWQNrap+a25gl+9p4ySDUvtwrmobc7b4ZfmwR CSaJWKL63x2t2NpaGrG8 =0f0Q -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome-shell and usability (from user perspective)
On 04/07/2010 12:54, Johannes Schmid wrote: Hi! Am Samstag, den 03.07.2010, 12:58 +0200 schrieb Maciej Piechotka: First of all I'd like to say that I'm not usability specialist (I'm not event 'normal' user - I'm closer to power user). However after some time of using the gnome-shell (from about GNOME 2.27.x) I noted a few problems - and they are more the minor problems (I believe) in design rather that 'bugs' so I decided to post it here. Why are you reposting the same message with different subject? I thought I check archive. Anyway, this list is not the proper place to discuss such issues. Grab the lastest gnome-shell from git I used untill now version from git using jhbuild and try it. If you still think you have valid points and they aren't reported as bugs on bugs.gnome.org, feel free to ping the gnome-shell designers on #gnome-shell or write a mail to gnome-shell-l...@gnome.org. Regards, Johannes Ok. Sorry and thanks for direction. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome-shell and usability (from user perspective)
First of all I'd like to say that I'm not usability specialist (I'm not event 'normal' user - I'm closer to power user). However after some time of using the gnome-shell (from about GNOME 2.27.x) I noted a few problems - and they are more the minor problems (I believe) in design rather that 'bugs' so I decided to post it here. I know that GNOME 3.0 is near but I guess it should be somewhere addressed (possibly in GNOME 3.2) - Application-based navigation in gnome-shell may be nice idea but in some cases it has no high usability. If someone have more than one document it can be hard to navigate - all I have is white boxes with some text. The fade-out provides little clue where should I find an application. There *are* names and I can use recent items but there are some problems with this approach: 1. It does not work for terminals as they are not documents. 2. Recent items can get spammed by some applications - for example seeing 160 photos from camera destroys the whole list Anyway the problem is not that it is not impossible. The problem is that it is harder. - Working with workspace is harder. When I had gnome-panel I had about 8 workspaces constantly opened and I had 1:1 relationship between tasks and workspaces. Now I use one workspace. The problem is the change from 'array' approach to 'linked list' approach. Also I cannot rearrange them or insert workspace in the middle. I also cannot rearrange freely the workspaces. I had the set up where all programming tasks was next to each other etc. - It is less about me but the notes about redesign nautilus. All 'normal' users I know do not use toolbars and keyboard shortcuts. If they want to save they go to File|Save even if disk is on toolbar. If they want to print they go to File|Print even if printer icon is on toolbar (some if they want to exit goes to File|Save and then File| Close). While getting rid of menus may be argued as simpler etc. it may be perceived as harder for users which have some experience with computers but do not understand how does it work (and they have some superstitions). (On the other hand simplifying menus seems a good idea). I understand that gnome-shell is probably targeted at users who are not necessary familiar with computers. However after some time of using gnome-shell I find it *less* task-based and harder to use using my work flow. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
A few notes about the direction in which gnome desktop is going
First of all I'd like to say that I'm not usability specialist (I'm not event 'normal' user - I'm closer to power user). However after some time of using the gnome-shell I noted a few problems - and they are more the minor problems (I believe) in design rather that 'bugs' so I decided to post it here. I know that GNOME 3.0 is near but I guess it should be somewhere addressed (possibly in GNOME 3.2) - Application-based navigation in gnome-shell may be nice idea but in some cases it has no high usability. If someone have more than one document it can be hard to navigate - all I have is white boxes with some text. The fade-out provides little clue where should I find an application. There *are* names and I can use recent items but there are some problems with this approach: 1. It does not work for terminals as they are not documents. 2. Recent items can get spammed by some applications - for example seeing 160 photos from camera destroys the whole list Anyway the problem is not that it is not impossible. The problem is that it is harder. - Working with workspace is harder. When I had gnome-panel I had about 8 workspaces constantly opened and I had 1:1 relationship between tasks and workspaces. Now I use one workspace. The problem is the change from 'array' approach to 'linked list' approach. Also I cannot rearrange them or insert workspace in the middle. I also cannot rearrange freely the workspaces. I had the set up where all programming tasks was next to each other etc. - It is less about me but the notes about redesign nautilus. All 'normal' users I know do not use toolbars and keyboard shortcuts. If they want to save they go to File|Save even if disk is on toolbar. If they want to print they go to File|Print even if printer icon is on toolbar (some if they want to exit goes to File|Save and then File| Close). While getting rid of menus may be argued as simpler etc. it may be perceived as harder for users which have some experience with computers but do not understand how does it work (and they have some superstitions). (On the other hand simplifying menus seems a good idea). I understand that gnome-shell is probably targeted at users who are not necessary familiar with computers. However after some time of using gnome-shell I find it *less* task-based and harder to use using my work flow. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Tue, 2010-06-15 at 09:36 -0400, Behdad Esfahbod wrote: On 06/15/2010 09:27 AM, Josselin Mouette wrote: Le mardi 15 juin 2010 à 08:21 -0400, Behdad Esfahbod a écrit : So, my application uses libraries A and B. It takes a GtkWidget from A, and passes it to a function in B. If A links against gtk-2.0 and B links against gtk-3.0, tell me exactly how does symbol versioning address this? It doesn’t, of course. It will not magically solve all coinstallability problems, just a subset of them. As soon as the application exposes widgets from both libraries, you’re pretty much doomed. So, which problems *does* it solve? (except for inferring minimum version of the library required at runtime) Isn't GTK+ by nature designed such that all widgets eventually are painted by on version of the library, and hence simply no way to have two in process without passing structs from one to the other? Plus, what would you do to glib's type system? Only one of the Gtk's can add the gtype GtkWidget. Which means, it wouldn't work even if not passing structs from one version to the other... As far as I understand it helps with the 'hidden' dependencies. I.e. if package A depends on B which depends on D in version 1.0 and A depends on C which depends on D in version 2.0 but B and C does not expose D interface. If D is libpng B may be gdk and C may be imagemagic. Both links against the same library (D) however both do not expose the ABI and hence it do not clash. In general it should help (I believe) if A does not depend directly on D (not only in terms of linking symbols) - I guess the in gtk+ it won't help but there may be some cases when it helps with glib. However please correct me if I'm wrong. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New external dependencies for Rygel: GUPnP Libgee
On Tue, 2010-06-08 at 02:24 +0300, Zeeshan Ali (Khattak) wrote: Hi Frederic, Thanks for the very quick reply. My reply below: On Tue, Jun 8, 2010 at 1:52 AM, Frederic Peters fpet...@gnome.org wrote: General questions first: - Are there frequent releases of those? The GUPnP libraries, yes! libgee used to be very frequently released until recently when the new maintainer just disappeared after he moved to a new house. That said, I haven't seen any issues with Libgee after 0.5.0 release and if I (or anyone) do, I'm sure Jürg will take over and make the releases happen in time. Right Jürg? Bug fixes seems to be pushed to git tree (however after them it seems that there was no 0.5.1 release). I can resume work on sorted collections (I was suppose to write skip list implementation) as soon as there is any chance of pushing it. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Versioned symbols for 3.0?
On Sun, 2010-05-23 at 01:11 +0900, Josselin Mouette wrote: Le mardi 18 mai 2010 à 12:32 -0400, Behdad Esfahbod a écrit : As for not wanting to use versioned symbols, could you provide more information why such a decision was made? I can't speak for Matthias, but I guess it's because no one pointed out what currently-existing problem exactly it's trying to solve. The use case that Patryk mentioned is a bit RPM-specific. As Emilio explained, DEB-based distros have other mechanisms to cope with this, and AFAIK Gentoo isn’t really affected by versioning issues. Gentoo is not affected by this specific issue. However there are problems with change of the ABI packages in general - like from jpeg 6-7 or libpng 1.2-1.4. They results in massive rebuilding even if lafilefixer and --as-needed are used[1]. Keeping old symbols would allow to avoid rebuilds (however if gtk+/gobject does not change ABI it is not affected at all). Regards [1] Both techniques combined are for keeping only direct references in the ELF files and libtool files so that if A uses symbols from B and B uses symbols from C but A does not uses symbols from C then if C changes ABI only B needs to be rebuild. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependency review
On Thu, 2010-05-13 at 18:11 -0400, Matthias Clasen wrote: hal used by tracker (?), suggested by others - drop ? Hal is unmaintained and obsolete since some time already. Anything should switch to udisks/upower/(g)udev (however there might be problems with non-linux platforms). I have tracker (0.8.x) on halless system BTW. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sun, 2010-04-25 at 19:01 -0500, Cody Russell wrote: On Sun, 2010-04-25 at 22:44 +0200, Patryk Zawadzki wrote: On Sun, Apr 25, 2010 at 7:59 PM, Curtis Hovey sinzui...@verizon.net wrote: My suggestion is to support the Zeitgeist's community's culture of code reviews. GNOME does not have an official code review tool. Neither does GitHub, which is why projects that host in GitHub also use Launchpad for code reviews. Actually this is not true. GitHub lets you review any commit and the usual workflow is fork → commit → request pull → get review. Eh, github's pull requests are not really the same as a code review system. At least last time I looked at it. You do a pull request and the person you're requesting basically just gets a message that says, Hey dude, check out my awesome code! There isn't a nice UI for doing the code review, with diffs that can be commented on and whatever. I cannot say if it is nice but github have since some time option to comment code/diffs. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSoC Proposal: Scripting Framework for Applications
On Tue, 2010-04-06 at 18:24 +0200, Johannes Schmid wrote: Hi! I am not entirely sure but my guess is adding support for another language would require modifications to all the applications individually that want its support to be included. As far as I have read (I apologize if I am wrong) GObject-introspection just makes language bindings pretty straightforward but to be able to use a language for scripting requires more than bindings; there are other issues involved for example, mechanism for invoking the script, passing objects, data conversion from the scripting language to the language of the application (usually C\C++), etc. That's not true. By adding gobject-introspection you get language-bindings for at least JavaScript and Vala out of the box and python is planned. There is nothing else to do as the bindings are constructed a runtime (vala: compile-time) from the introspection files. If I understand you still need to *load* plugins. While gobject-introspection do simplify exporting/importing objects (in runtime or compile time) it does *not* handle loading scripts and running hooks. You still need to add support by hand - otherwise there would be no 'javascript only' gnome-shell. The two uses-cases I mentioned are similar to what you are suggesting. In my opinion, these two extremes do seem to have a fair bit of similarity and hence they can be supported using a single scripting framework. Moreover, attempting to unify them would save some code bloat since a single solution is always better than two overlapping ones. Well, would a single solution have so much benefit? Of course you might be able to unify the way plugins are loaded and plugin descriptions are designed but this is actually not much code as most things a handled by GModule anyway. Much more important is the point that any application has it's own plugin API anyway, as the plugins have to interact with the internal architecture of the application. Example: gedit and anjuta both use gtksourceview. But a plugin in gedit is able to interact directly with the gtksourceview class while anjuta supports different editors and as such has an interface called IAnjutaEditor which is used to interact with the editor. A unified framework won't help you here at all. I'm not quite sure how much code/time is spent on this but you still need to hook the single languages into the stack. Last time I checked C/python/vala was used. gnome-games seems to use a bit guile. If user knows lua/ruby/fortran/shell/javascript - he's out of luck. You reinforced my point ;-) . Having a proper scripting framework would avoid having to modify/update each application individually in order to support any new technology in future. Same goes if for example, as you say, python bindings become more mature: individual applications would not have to be updated to add support for this new language. See above. The internal APIs need to be exposed anyway and gobject-introspection is the best way to do it. I wonder what would be left for the Scripting Framework. BTW, could you explain what components this scripting framework should have, which languages it would support, etc.? I cannot answer for author but I'd imagine that: - Searching plugin directories for plugin - Detecting the language of plugin (ok. assembler is not the language plugin is written in but that's different matter). - Loading/unloading plugins according to given configuration. Setting the python/guile/haskell/lua/tcl/brainf*ck/whitespace/javascript environment. Possibly it should handle dependencies between plugins. Probably languages should be GModule plugins itself. I don't know if it is enough for GSOC project but it is at least so boring task many programs have no more then native+python scripting. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Udisks, Upower, external deps and jhbuild
On Wed, 2010-03-17 at 16:05 +0100, Luca Ferretti wrote: udisks[1] and upower[2] have now a tarball release; what should we do on 2.30 external deps page[3]? Should them replace or put beside DeviceKit-* ? Here is any official module still using DeviceKit-* ? Plus, any idea about JHbuild? I remember some issues building DeviceKit-* maybe related to stuff needed to build (udev, mostly)... Cheers, Luca [1] http://lists.freedesktop.org/archives/devkit-devel/2010-March/000758.html [2] http://lists.freedesktop.org/archives/devkit-devel/2010-March/000747.html [3] http://live.gnome.org/TwoPointTwentynine/ExternalDependencies BTW. Some packages need udisks already (like gnome-disk-utils). Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Wed, 2009-10-14 at 11:46 +0100, Emmanuele Bassi wrote: everyone asking for a plain text format (or even an XML format) for *storage* should be forced to get only that on their machines, but should also be barred from complaining why their boot process takes a minute instead of 10 seconds. and no: having plain text storage and adding a binary cache is not a solution. ciao, Emmanuele. There are key differences: - FS are usually implemented very carefully. They tend to be part of kernel. On the other hand desktop applications are designed much more 'speedy'. Sometimes application hangs (much more frequent then kernel locks IMHO), sometimes it crashes. - FS have much better support of tools which recover the data. Well - you cannot edit by XML editor but both FAT and EXT2/3/4 have numerous tools that recovers data - even less popular systems like reiserfs have them. I haven't seen them for many application binary format. - The more common code the more profitable optimalization is. If the format is read once at startup it makes much more sense to have it more readable then fast. On the other hand if it is used constantly... - Hardware limitations - on paged systems with big costs of switching etc. it makes sense to have data padded. It simply makes sense to be able to read in 512 kB - 4096 kB blocks. Unpadded format would be much more costly (it would required to look for end of metadata and possibly copy from one place in memory to another). However one page is load looking through it is cheap as it is already in random access memory. Since even cache operates on virtual memory as long as block is continuous it makes practically no difference in speed. - FS are rarely compressed. Text-based formats are much compressable and backup of them would take much less space. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Wed, 2009-10-14 at 15:54 +0100, Alan Cox wrote: Sorry if I not made it clear - I'm against putting everything in binary which does not mean that binary format is ultimately evil. Probably XML is not the easiest format to parse. I am still a bit 'scared' by idea of binary format unless it is needed (I'm having no problem with binary cache - although I understand why it has no place here). - FS are usually implemented very carefully. They tend to be part of kernel. On the other hand desktop applications are designed much more 'speedy'. Sometimes application hangs (much more frequent then kernel locks IMHO), sometimes it crashes. Desktop application software mostly sucks. I wouldn't argue with that, but the libraries used at the low level are mostly good clean code. I agree that many libraries are well-tested but I rather concentrated on 'why FS are binaries while the desktop-formats are text-based'. - FS have much better support of tools which recover the data. Well - you cannot edit by XML editor but both FAT and EXT2/3/4 have numerous tools that recovers data - even less popular systems like reiserfs have them. I haven't seen them for many application binary format. So write one. The format is visible, the code is open source. You should just need xml2vomit and vomit2xml or whatever format data you use. There is no problem in writing such tools if format is kept intact (no corruption). Writing recovery tools on the other hand requires more 'manhoures'. - The more common code the more profitable optimalization is. If the format is read once at startup it makes much more sense to have it more readable then fast. On the other hand if it is used constantly... That argument is garbage. It's one reason why Gnome takes forever to start up. As a normal use you regularly start applications and desktops, you almost never go and emacs the XML file. Take 20,000 distro Gnome users, what percentage of them do you think have ever hand edited their configuration, what percentage do you think have ever used things like gconftool. For that matter what percentage of normal users do you think even understand the question Have you ever hand edited your gconf database They all start the desktop up, they all bitch about it taking forever. 1. Most of the (GNU/)Linux start up system and configuration is text. Why there is no performance problems there? The only binary file in /etc I heard about are terminfo files. 2. I have rather old computer. Gnome starts in less then minute (although I have not measured it). 3. I'm not speaking about users - I'm rather speaking about the programmers. It is much easier to debug text formats then binary formats. As far as power users are concerned - they will easier recover data after some time from text-based format then look for documentation of old format. In current gconf if they don't know where the value is they may be not emacs the file (as it won't be noticed by gconf - at least in past) but they may find it using standard tools like find/grep etc. looking through it is cheap as it is already in random access memory. Since even cache operates on virtual memory as long as block is continuous it makes practically no difference in speed. Reality check. On a modern hard disk a good rule of thumb is that reading 512Kbytes of data costs as much as a single sector read. So you want all your metadata in a single linear file loaded once, in order. Now whether that is something looking like rot13 encoded vomit, beautifully spaced and formatted XML or a database format is less important because the rotational latency and seek latency of the disk dominate any processing time unless your data format is extremely bogus. Point taken. - FS are rarely compressed. Text-based formats are much compressable and backup of them would take much less space. The same *information* should compress to the same size irrespective of the input. Thats a mathematical theoretical case but reality isn't far off providing any padding is consistent. Hmm. AFAIK in some cases compressed XML files were better then designed binary formats in terms of disk-space efficiency. You don't want to compress critical backup data anyway because it means a bit error on the backup media costs you vastly more data. Well. Settings are usually important but not critical. Home backup usually rely on compressed data. The only sense by which text compresses is better is the because it was larger and more wasteful to begin with sense. From mathematical standpoint you are right. From practical - well at least sometimes compressed text is smaller then the binary. Shrug.. pluggable back ends would be nice anyway. I'd rather have my base preferences in hesiod BTW - what's hesoid? Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list
Re: What does gnome-shell give us?
On Fri, 2009-10-02 at 14:38 -0500, Shaun McCance wrote: On Fri, 2009-10-02 at 18:56 +, Colin Walters wrote: On Fri, Oct 2, 2009 at 6:46 PM, Shaun McCance sha...@gnome.org wrote: On Fri, 2009-10-02 at 18:37 +, Colin Walters wrote: * Actual design for how workspaces behave (We didn't really have this in any consistent way, but now is an opportunity to fix it right, e.g. make moving an application to a workspace a persistent operation, etc. Actually a lot of cool things are enabled when we have an application based system) Please excuse my ignorance here. Are you saying that an application as a whole (i.e. all of its windows) exists on only one workspace? Like the very broken way workspaces behave on OS X? Well...I don't want to dive into design, more note that the possibility exists to improve things given that we have two fundamental improvements in having application tracking, and fixing the split between UI and WM. All right, I'm not trying to troll here. But I'm working very hard on revamping the user experience in Yelp to keep it more focused on the content you're looking at. Yelp would be very broken if it were constrained to a single workspace. In fact, Yelp windows should generally feel more like utility windows than a part of the Yelp application. It's important to me to know design points like this. I've seen precious little communication about this sort of stuff. I see whizbang screencasts from time to time, but I haven't really seen real dialog about the user experience that we're trying to create, especially with respect to how it impacts the rest of the desktop. Hmm. I guess that other applications which should not be one-workspace-only include at least: - gedit - gnome-terminal In fact I'm not able to think about 1 application which I'd like to have on one workspace except maybe gimp (but they are fixing it). I prefer solution one-workspace-per-task and different tasks may involve the same programs. I cannot see how it works in practice unfortunately (mutter refuses to start-up on my hardware). Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What does gnome-shell give us?
On Sat, 2009-10-03 at 00:03 +0200, Rodrigo Moya wrote: On Fri, 2009-10-02 at 20:57 +0100, Maciej Piechotka wrote: In fact I'm not able to think about 1 application which I'd like to have on one workspace the only few I can think of are some that you really want 1 instance of: * mail application (evolution) * IM (pidgin, skype, xchat, etc) 1 instance is not one window. I have usually empathy opened on #gee on workspace when I'm working on gee, #haskell where I program in haskell etc. Still if I'm working on some longer email I may want to have opened mail about something on one workspace and different on another. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
On Wed, 2009-09-30 at 12:20 -0600, Wolter Hellmund wrote: Greetings, I am a new member of the GNOME contributors community. In the following message, I will suggest the creation of a new project entitled GNOME Innovation in HTML format for easier comprehension. Please use ASCII. Some people may use even CLI newsgroup clients (via gmane). (...) Ok. The only feature different then bugzilla is vote down AFAIU. Moderation is similar to marking NEW and vote up to adding to CC. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
On Wed, 2009-09-30 at 13:57 -0500, Shaun McCance wrote: On Wed, 2009-09-30 at 20:40 +0200, Maciej Piechotka wrote: On Wed, 2009-09-30 at 12:20 -0600, Wolter Hellmund wrote: Greetings, I am a new member of the GNOME contributors community. In the following message, I will suggest the creation of a new project entitled GNOME Innovation in HTML format for easier comprehension. Please use ASCII. Some people may use even CLI newsgroup clients (via gmane). (...) Ok. The only feature different then bugzilla is vote down AFAIU. Moderation is similar to marking NEW and vote up to adding to CC. Note that bugzilla does have a voting feature. We explicitly do not enable it. No. You explicitly changed it to CC system ;) - if something is worth it user agree to get spammed by updates ;) Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
On Wed, 2009-09-30 at 13:11 -0600, Wolter Hellmund wrote: Well, I am really sorry for using HTML. I thought it would be liked. Ups. Sorry if I was too mean. I'm just somehow old-style person who still uses USENET ;) AFAIK HTML in email is not liked very much among at least some old-style people. Probably because it makes processing harder etc. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump minimum version of poppler to 0.12.0
Am Donnerstag, den 10.09.2009, 13:20 +0200 schrieb Maciej Piechotka: Isn't this version of poppler breaking some packages from texlive? Any bug report ID? andre It was masked in portage. Now it is unmasked so It's either fixed in Gentoo or upstream. Anyway - patch exists. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Sound system - user perspective
I spotted an area in which Gnome desktop can offer better user experience. Imagine I use VoIP (skype, empathy or anything like that) and some music player (Banshee, Rhythmbox etc.). I listen to some music or a podcast when someone ring. I have to stop the music and answer the phone. However I guess that music/podcast should actually be paused (i.e. state in application should be stopped) instead of being just volume down. I'm not sure if current architecture would allow such integration and probably it would require changes to few packages (music player and empathy at least) I prefer to post the idea here firstly. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Autostart programs made easy
Sorry for posting two posts one after another. I do so as they are on different topics. If I should do it in one post - please just say so I'll do it such way in future. I always found adding new startup programs a bit tricky. I need to fill several fields to create new .desktop file. However most of the time what I really want is create an starup for existing application. The only problems I see is: 1. Most of programs I'd like to see in minimised view (either minimized or hidden in tray). I don't know how it is with gnome-shell but I just don't want them on front view. It can be treated with gnome-shell or wm/gs integration or parameters to application. In the last case it may require some changes to .desktop format. 2. Probably the best would be softlinks to original .desktop files. In case when such file is missing: - Search with similar naming (lower/upper case etc.) - Ask user what to do Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound system - user perspective
On Sun, 2009-09-13 at 20:11 +0200, Lennart Poettering wrote: On Sun, 13.09.09 19:18, Maciej Piechotka (uzytkown...@gmail.com) wrote: I spotted an area in which Gnome desktop can offer better user experience. Imagine I use VoIP (skype, empathy or anything like that) and some music player (Banshee, Rhythmbox etc.). I listen to some music or a podcast when someone ring. I have to stop the music and answer the phone. However I guess that music/podcast should actually be paused (i.e. state in application should be stopped) instead of being just volume down. I'm not sure if current architecture would allow such integration and probably it would require changes to few packages (music player and empathy at least) I prefer to post the idea here firstly. This logic is actually already supported in PulseAudio and activated by default. This all depends on that applications properly tag their audio streams, i.e. so that it is clear which stream is telephony, which one is event sounds, and which one is music. Some apps have now started to do this properly. In fact the next beta of Skype will do this too. And if your favourite telephony or music app still doesn't then please complain and file a bug and ask them to read this: http://0pointer.de/blog/projects/tagging-audio.html and this: http://pulseaudio.org/wiki/ApplicationProperties The logic in PA will mute every stream tagged as music as soon as a stream tagged as phone is active. It will also send an asynchronous event to each music playing client requesting that it should pause its playback. If the phone stream goes away the music streams will be unmuted again and the apps notified that it is a good idea to unpause playback again. I heard about tagging but I haven't heard (till your mail) about sending event. Unfortunately GStreamer does not have a nice API for tagging streams yet (this limitation can be circumvented via using environment variables which PA will pick up, but that's not a very nice solution). Also, GStreamer does not actually forward the pause request message to the applications and hence you'll effectively only see the muting taking happen, not the pause/unpause in current media players. To make this all work nicely jut a little bit glue code needs to be written for Gst and some minor patches be prepared for the various telephony apps/media players. If someone wants to pick this up and push this through this would be really great! Lennart Ok. Since the problem is in gstreamer I'll try to fill bugs against it (or CC existing). Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Request for removing clutter in current form
On Mon, 2009-08-17 at 07:43 +0100, Emmanuele Bassi wrote: On Mon, 2009-08-17 at 08:03 +0200, Xavier Bestel wrote: Le dimanche 16 août 2009 à 23:55 +0100, Emmanuele Bassi a écrit : the majority of GPUs, nowadays, work fine on Linux with open source drivers[1], and provide the basic functionality that Clutter requires[2]. Except for some Intel cards, that's not true by a long shot. Only very old ATI cards are supported, you can't buy a card retail (current radeon HD4000 or even HD3000 or HD2000) that works in a current distribution or even in the next batch of distribs (they are in alpha state already and the drivers don't exist yet). NVIDIA are of course not supported at all by OSS drivers (nouveau is progressing slowly). Things are changing, but it'll be something like a full year before end-users see all working on their desktop for ATi cards and more for NVIDIA. so you're saying that only old GPUs work, and Maciej is saying that old GPUs do not work. it would be interesting to have a single place where the hardware support matrix was stored -- maybe on live.gnome.org or on freedesktop.org's wiki -- and updated. ciao, Emmanuele. I talked with the people from #radeon and freedesktop bugzilla. The problems with GL I had was due to composition enabled in metacity (or in fact any composition - it's not metacity bug - kwin/compiz would do the same). The solution is KMS/DRI2, which for radeon just landed as highly experimental in kernel (and AFAIK are not released yet as drivers for xorg but will be soon). Here's starts the steps. In KMS-enabled system as many GTK+ apps redraw frequently there are many flushes to kernel. As a result it is unusable on xorg-server 1.6 on my, older, system. gnome-terminal cannot be scrolled and glxgears have 7-11 FPS instead of normal 200-220 FPS. I was advised to use xorg-server 1.7 if I'm 'feeling tester-like'. It was pointed out by someone that on KMS (s)he is using xfce-theme as more lightweight. As for sure KMS will improve before 2.6.32 I still feel that introducing OGL know is a bit too early. Hopefully it is just one kernel release too early. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
RE: Waiting for GNOME 2.30 (=3.0)
On Sat, 2009-09-12 at 17:39 +0100, Uros Nedic wrote: Thank you for answer. When someone joined on this list for only a month, it is very hard to track everything what has been discussed. Some digest like this always helps. Regarding 3D, do you plan to implement Gallium3D approach or you will do it in old fashioned way? Uros AFAIK Gallium3D is rather an architecture of drivers then public API. OpenGL (DirectX from Wine - whatever.) uses Gallium3D under the hood but you are suppose to use OGL/DX etc. interfaces instead of G3D. Therefore G3D as it have nothing directly in common with Gnome. It will use OpenGL API, which in future will be based on G3D drivers - but from programmer standpoint (or user if we exclude speed) there is no difference (you use the same API). Gallium3D is 'interesting' only for driver writers. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump minimum version of poppler to 0.12.0
On Thu, 2009-09-10 at 11:06 +0200, Carlos Garcia Campos wrote: Poppler 0.12 is the new stable release. Although it doesn't add any new API and evince builds with earlier versions, I suggest to bump the minimum version because this release includes a lot of important rendering and performance improvements, specially in the cairo backend: blend modes, linear/radial patterns, tiling patterns performance, ... Ok? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list Isn't this version of poppler breaking some packages from texlive? Is it fixed? In such case it would make Gnome adoption in distributions longer. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
