desktop December 2013

desktop@lists.fedoraproject.org

32 participants
15 discussions

Update to the PRD draft
by Christian Schaller 16 Dec '13

16 Dec '13

Hi, So after going over the emails on this list and looking over the PRD I have tried to clarify the Mission statement. The new text should hopefully both make it even clearer that general users are welcome to use Fedora and at the same point by using the term 'Fedora Workstation Working Group' instead of 'We' I made it more clear that the goal of the PRD is to govern the work of the working group, not the use of the individual users of the product. Christian

2 1

Re: Criterion revision proposal: KDE default applications
by Adam Williamson 16 Dec '13

16 Dec '13

On Fri, 2013-12-13 at 05:31 +0000, "Jóhann B. Guðmundsson" wrote: > On fös 13.des 2013 02:05, Adam Williamson wrote: > > It was clear at the Go/No-Go meeting today that KDE SIG does not > > consider this release criterion applicable/desired: > > > > "All applications that can be launched using the standard graphical > > mechanism of a release-blocking desktop after a default installation of > > that desktop must start successfully and withstand a basic functionality > > test." > > > > https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_app… > > > > jreznik says they consider the live image their 'polished product' where > > everything must work, while the DVD install is more of a grab-bag - they > > install a whole bunch of stuff, and don't think it's the end of the > > world if one or two bits are broken. > > > > Given that, I propose re-wording as follows: > > You are trying to fix the problem on the wrong end thus leave the > criteria as is. > > The installing should not differ ( or in other word be consistent ) > regardless if you install from the live or from the dvd the end result > should be the same. > > You should have the same service enablement, the same desktop instalment > and experience etc. > > So get releng to get their act together and fix that for the dvd so > matches with the live. Per my long reply on the other sub-thread, I'm fine with that if it actually _happens_. But it's not releng's responsibility; it's the KDE and desktop SIGs. They own this stuff: it's their responsibility to choose what packages go in the lives and what packages are deployed when you do a DVD install of their desktops. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

7 15

Criterion revision proposal: KDE default applications
by Adam Williamson 13 Dec '13

13 Dec '13

It was clear at the Go/No-Go meeting today that KDE SIG does not consider this release criterion applicable/desired: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_app… jreznik says they consider the live image their 'polished product' where everything must work, while the DVD install is more of a grab-bag - they install a whole bunch of stuff, and don't think it's the end of the world if one or two bits are broken. Given that, I propose re-wording as follows: "All applications that can be launched using the standard graphical mechanism of a release-blocking live image after an installation of that image must start successfully and withstand a basic functionality test." So, that doesn't just apply to KDE. True, but I actually think it's a reasonable revision for GNOME as well. It makes sense to see the live images as defining what our 'polished core desktops' consist of, and the DVD as more of a grab-bag of packages. The lives will (should) always contain the bits the desktop SIGs think are absolutely key pieces of the desktop. And I think we could generally do with a bit of criteria watering-down; we're starting to do a lot of fudges and waives, which indicates the criteria are currently too tight for us to realistically enforce. Things are better when we can stand solidly behind the criteria without fudging stuff. CCing KDE and desktop lists. If folks feel that we should restrict this change to KDE only, please do yell, but I'm kinda liking the simple version. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

4 8

Re: Updated Fedora Workstation PRD draft
by Marcel Oliver 02 Dec '13

02 Dec '13

Doing some idle web-browsing, I came across this recent thread, which I found very interesting. Let me start by introducing myself: I am an academic, working in computational mathematics, which has me run simulations and data analysis some, usually a small fraction of my time, write (using LaTeX), and do ordinary office tasks a (too large) fraction of it. I started running my first self-owned Linux box with Redhat 4.2 and have pretty much followed all of the Fedora releases, maybe skipping an occasional few. So the fact that I ended up reading fedora-desktop at all indicates in some way that there is lingering dissatisfaction with the state of Fedora, but a lot of the comments expressed I find encouraging enough to try to spend time to put my thoughts down in a consistent way. First some historical remarks. Up until Fedora 14, I was actually looking forward to new releases as, despite of occasional breakage, there was a steady increase in quality and capabilities. The point when Fedora, in my experience, really blew it was the transition to Gnome 3 in Fedora 15, and for two independent reasons: (a) The sudden requirement to have working accelerated graphics drivers in the default install broke the default install on several perfectly good systems. (b) Pulling out fundamental UI paradigms from under one's feet feels in some way like bodily assault, as all carefully learned workflows and muscle memory suddenly start bumping you every step you take while trying to get real work done. Note that this is not a general critique of Gnome 3 which, with some reservations I will comment on later, I find interesting and a perfectly acceptable approach from a UI development perspective. What I object to (I have to admit that it makes me angry to this day) is that it is considered acceptable at the distribution level (!) to break user's setup (hardware as well as workflows) in such fundamental ways without providing adequate fallbacks. I have heard technical arguments why this was not possible, and these are possibly strong arguments for all I can tell, but the mere existence of Mate today attests that the pain for the developers cannot have been insurmountable. I also do appreciate the fact that the transition to an accelerated desktop has probably given a good push to graphics driver development. At least all of my systems noadays run fine in accelerated mode. Still, all this is no excuse for breaking user systems at a fundamental level without having a fallback that is at least as good as what worked in the past. To put it another way: as a technically minded user (not system developer!), I do appreciate living on the bleeding edge and do not mind filing the occasional bug report or working around upgrade-related problems, but part of the unspoken deal is that I should not fear that the distribution pulls the rug from under me. If Fedora cannot maintain this fundamental trust, it will lose testers, early adaptors, and end users. So to get the main points, let me state a few principles of how I would like "my" distribution to be: 1. Chose evolutionary over revolutionary changes whenever possible. 2. Do not remove features (even misfeatures - someone might rely on them) without really good reason (pure aesthetics is a good reason, IMO, but not a "really good reason"). If you do, do it a prepared and well-documented way. 3. Treat "developers" as users who are pushing the envelope more than others, not as a fundamentally different group. A good distribution, UI, desktop, you name it should scale well from novice users to specialists. Trying to draw a line will alienate people on both sides of it. 4. Don't let any one desktop environment define the distribution. The task of the distribution is to _integrate_ different pieces of software so that they can be used together without interference or pain. 5. That said, desktop environment proliferation is not part of a solution, it is part of the problem. For 1: There are some big changes that appear to work (at least from my perspective, the systemd transition was such as case - it surprised me rather unpleasantly when forced to debug a nonbooting system after gdb decided it would only work with accelerated graphics drivers, but the new workflow was sufficiently well documented and coherent so that this was ultimately a non-issue), but in most cases the pain of throwing away a well-understood codebase for something new seems to outweigh the gains by far (here the anaconda and fedup transitions are a case in point). For 2: This appears to be well understood in kernel and basic infrastructure circles, but at higher levels in the stack, this mindset is IMO underdeveloped. For 3: In my experience, I run into either technical issues or usability problems more often when doing "developer" work, but the issues are not necessarily qualitatively different from "ordinary" computer use. Typical situations that a "developer" encounters (many open windows, independent parallel instances of applications, long-running jobs that produce occasional feedback and need monitoring from time to time, running jobs and/or keeping user data on the LAN or even "in the cloud", large amounts of installed applications (because various users on the network have different preferences) are just expressions of a scalability regime which includes the "ordinary" user in the center. Thus, any improvement in handling "extreme" behavior will benefit all users in the end. For 4: From a user perspective, the problem is not that all g* or k* applications should maximally look and behave alike. That's a task for purists and the respective upstreams. As a user, for the better or worse, I am exposed to a variety of different electronic devices, operating systems, applications of various heritage, web applications, etc. So consistency for me is always relative to what's out there in the world, not to the best-practice example from a small homogeneous software ecosystem. So the distribution should treat all software as equal and make sure it works optimally in a heterogeneous software environment. Here my main gripes are: - Currently I have Gnome, KDE, and cinnamon installed (that is on my personal desktop where it might be of questionable value, but in a workgroup/university setup, this is commonplace). The menus are a terrible mess of triplicate utilities without structure, generic names, sometimes identical looking entries which are difficult to navigate if one does not already know what one is looking for. - No clear separation between system configuration and desktop configuration. I don't need three printer configuration utilities, I need one that works. These are distribution-wide issues, not desktop issues. (I can see that the different desktops like to roll their own thing, and that is fine with me. However, the distribution should go for one option which is the optimally maintained one and use it from all other desktops. For a users it does not make ANY difference if it's the Gnome or cinnamon or KDE tool or something entirely different as long as it is logically laid out and it works.) - At higher levels in the stack, distributions should choose best-of-breed default applications, not necessarily those who are the "official" desktop environment champions. Case in point: I have always been biased toward using Gnome rather than KDE applications when both exist, with one exception: As a document viewer (and that's a pretty central complex application), okular is such an advance over evince that IMO it really deserves the "Document Viewer" name in the defaults. (The main points: using the "trim margin" feature of okular, most PDF documents which occur in the wild can actually be read at an acceptable magnification without in-page scrolling on modern screens; the page caching of okular is notably better than evince's which is unacceptably slow with bitmapped, i.e. scanned documents even on good hardware.) So Fedora should bundle what is the best, not what is the "politically correct" application for a given desktop. For 5: I would very much wish if Fedora would take a lead in unifying at least the Gnome based desktops (Gnome 3, Gnome classic, cinnamon). They all have the same underlying infrastructure, which appears sound for all I know, and the differences are IMO more political than anything else. To be precise, I have to say that from an aesthetic perspective, I like Gnome 3, and at least in principle I agree with the philosophy that one should not need hundreds of configuration options if the defaults are well chosen and the important ones are there. However, and this is what I feel is most relevant to the "developer" discussion: Gnome 3 default fails for me mainly due to the missing taskbar. (I know there are extensions, but that is beside the point.) I'll start by saying that, from a purely aesthetic perspective, I actually dislike the taskbar: it is taking vertical screen real estate from me and it starts looking ugly, with ridiculously shortened application names, when the number of windows gets large. Unfortunately, this is precisely the regime when the Gnome overview mode (I am using cinnamon right now, so I have both for direct comparison) becomes outright unusable. The problem with overview is that when there are too many windows, I cannot read, or can hardly read the text while, at the same time, I have no good sense of the mapping of the logical order of the windows to the display order in overview mode. The taskbar, while also unable to provide meaningful text, still has an accurate history of the order in which the windows where opened. This means that I can usually find the window I need surprisingly quickly and reliably while overview mode greets me with an unusable mess and even ALT-tab is often hard to use (e.g., I am comparing the output of an old and a new run after I fixed my code. The labeling of the two windows is identical, the output looks very similar. So which is which? No problem if I have a strict time line, impossible with anything else). Abstractly speaking, the problem is with best handling a number of 40-80 and more open windows, and here the taskbar is the least bad. (Windows seems to have a hierachical, application-based system, which I have not explored very much, and I am not sure if this is not incurring more problems than it solves.) A second workflow where I absolutely depend on the taskbar is for spotting small differences in graphical output or data visualization where I move one window over the other and flip the upper window on and off from the taskbar. This is arguably a very specialized use case ("developer/scientific workstation"), but is incredibly useful and without replacement in the Gnome 3 paradigm. So, if I could have a wish unconstrained by politics and internal technical issues, I would like to see the best features of cinnamon merged into Gnome classic and make Gnome classic a runtime (not start-up time) configurable option (maybe a set of related options) in standard Gnome 3. Call it even "expert mode" and hide it somewhat away from casual users. That would go a long way of reaching a wide range of users with a single setup and also reassure users that their workflows are welcome and long-term supported. I have toyed both with current Gnome classic and cinnamon, so for the record a list of features that make me (mildly) prefer cinnamon. I think they are relevant to get a "developer user" point of view: - Taskbar in cinnamon is right-clickable as it used to be in Gnome 2. - It is possible to configure a "vertical maximize" feature, which is more useful than the various edge-snap options as, especially for developer use, the width of windows is usually well-defined and should not be changed, but one often wants maximal number of viewable lines. I think it would make a lot of sense to make this feature defined (rather have it as part of a broad set of otherwise relatively uninteresting configuration options) - I came to like the "single taskbar at bottom" approach as I usually plug in an external screen into a laptop which is sitting physically above the (ultrabook) laptop, so I want it logically above, too. I did this for years also with the old Gnome 2, so the top bar on the primary screen is not a deal breaker, but in this secondary over primary screen scenario (which I think is the only natural one for the plug-into-laptop situation), it feels more natural not to have a top bar on the primary screen. Minor detail though. (Related to this, Gnome and Gnome classic had a persistent bug in this configuration which I filed but I don't think is fixed at least according to bugzilla, which is indeed a dealbreaker.) - The panel editing and configuration seemed very natural (better than when I tried Gnome classic), but this may be just a moment's impression, so I do not attach weight to this. I do like (most of) the the cinnamon defaults, though, in particular the relatively minimal vertical footprint of the taskbar, and the windows and virtual screen switcher. - I don't remember if this is only a Gnome thing or also a Gnome-classic thing: If I tell the UI to open a second instance of an application, I would expect a second instance and not to be shown the first. My conclusion is that there is nothing in cinnamon which could not be done in Gnome (classic) without a major break in design philosophy. (As much as I like cinnamon in general and appreciate the work going into it, lingering bugs (I have filed a few) make it look like the maintenance burden is at the brink of feasibility.) Two more remarks on what I find extremely important from a "developer" perspective: - Focus follows mouse (or sloppy focus) and - right/middle mouse copy/paste. I am mentioning this because I have seen these features, probably because they deviate from "expected" behavior in other operating systems, be relegated from standard in the old days to "dig deep in preferences", resp. talk about changing right/middle mouse behavior in Gnome. I have worked on systems without them, but I find them such tremendous productivity boosters that I keep coming back to them as soon as I can. (Note: I am writing this on a laptop which does not even have a physical middle-mouse, so I enabled three-finger tap to be equivalent to middle-mouse - this looks like a hack, but it's actually so convenient that I find myself using the three-finger tap even when, like now, I have a physical mouse attached. So again, this would be a good feature for standardization - I don't even care how it is mapped to taps or gestures as long as remains consistently reliably available on modern hardware.) OK, this was a long post, but I have the impression that there is actually an audience of Fedora developers somewhat appreciative of such ideas. I think it would buy Fedora a lot of trust if things were thought through from the workflows and needs across the spectrum of existing users, including specialists and "power users". I.e., be inclusive in your approach to the extent possible with honest effort, it's going to benefit ALL users. Regards, Marcel --------------------------------------------------------------------- Marcel Oliver Phone: +49-421-200-3212 School of Engineering and Science Fax: +49-421-200-3103 Jacobs University m.oliver(a)jacobs-university.de Campus Ring 1 oliver(a)member.ams.org 28759 Bremen, Germany http://math.jacobs-university.de/oliver ---------------------------------------------------------------------

4 5

Where can I find python bindings for evolution?
by Ankur Sinha 01 Dec '13

01 Dec '13

Hi, I'm looking for python bindings for evolution, the package debian calls "python-evolution"[1]. These bindings are required by some programs, such as gtg[2]. I've looked using yum etc., but not managed to find these files. Could anyone please direct me to the package, or source so I could package it up? (I maintain gtg and would like to get the evolution backend working). > [asinha@ankur-laptop ~]$ sudo dnf whatprovides '*/*evolution*/*.py' > orca-3.10.2-1.fc20.noarch : Assistive technology for people with visual impairments > Repo : @System > > orca-3.10.2-1.fc20.noarch : Assistive technology for people with visual impairments > Repo : fedora > > python-django-evolution-0.6.9-2.fc20.noarch : Schema evolution for Django > Repo : fedora > > ReviewBoard-1.7.18-1.fc20.noarch : Web-based code review tool > Repo : fedora > > [asinha@ankur-laptop ~]$ [1] http://packages.debian.org/wheezy/ia64/python-evolution/filelist [2] https://answers.launchpad.net/gtg/+question/240070 -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop December 2013