- Journal
- Council Notes: Oct 1, 2011
Council Notes: Oct 1, 2011
Submitted by cassidyjames on Mon, 10/03/2011 - 20:44Another week, another Council meeting. This week we went over some the blueprints from last week in more detail (while addressing the feedback we've received), in addition to going over some other important blueprints. Follow along for more details.
Maximize Like Fullscreen
https://blueprints.launchpad.net/elementaryos/+spec/maximize-like-fullsc...
Approved, but if and only if the hide is a result of maximize and both Plank and WingPanel always do the same thing. This makes maximization truly maximize the screen space the app uses, keeps thing behaving consistently, and is always the result of an explicit action.
Next Developer Sprint
Contractor
https://blueprints.launchpad.net/elementaryos/+spec/contractor-sprint
We've decided the next developer sprint should not be so open-ended, and that it will more productive to sprint on specific work items like bugs in a specific user-facing app. Sprinting on Contractor is still an option for down the line, but it would not be a traditional developer sprint.
Postler
Postler and Midori both have a huge amount of bugs reports on them, making them prime candidates for the next app sprint. Being based on Vala and generally a smaller app than Midori, Postler seems like the best bet sprint-wise. We will discuss it with the developer before the final decision.
Foreign App Defaults
https://blueprints.launchpad.net/elementaryos/+spec/foreign-app-defaults
We've decided this simply is not a good idea; it's not the job of elementary developers to take their time making non-native and third-party apps look and work right.
Non-traditional Filesystem
https://blueprints.launchpad.net/elementaryos/+spec/logical-filesystem-o...
Because we're already working to abstract the filesystem for end users, "normal people" will probably never see the filesystem; this would be more in the interest of power users and devs, who are already familiar with the Linux filesystem. We've decided to not approve this blueprint.
Ksplice
https://blueprints.launchpad.net/elementaryos/+spec/ksplice
We've decided to not implement Ksplice with elementary OS. Ksplice itself is no longer well-maintained and has not been tested in a large desktop OS to our knowledge. Instead, we will work to continue to handle updates as transparently and in the background as possible without bothering the users. The latest updates will always be used as soon as the user reboots.
Plank Defaults
https://blueprints.launchpad.net/elementaryos/+spec/plank-default-settings
We have decided to keep the 48px icon size from Jupiter, use this Pantheon theme, and to keep the same hiding behavior (for non-maximized apps). The size has worked well thus far, the theme is similar to Jupiter's dock theme (and is visually consistent with the other Pantheon elements), and the hiding behavior (when combined with the maximize-like-fullscreen blueprint) keeps things showing unless they're explicitly hidden.
Indicator Strategy
https://blueprints.launchpad.net/elementaryos/+spec/indicator-strategy
We've decided that the indicators should not contain launchers to settings areas, so we're going to see what happens when we remove Gnome Control Center. If the launchers remain in the indicators, we will work with upstream to get them to remove the launchers when Control Center is not installed. This way we don't have to maintain our own version of every indicator, but we also won't have useless launcher items that don't do anything.
Don't Support Installing Debs by Default
https://blueprints.launchpad.net/elementaryos/+spec/no-talks-to-strangers
As a security model it could be beneficial; a user can always install gdebi to make it less secure (but possibly more convenient for their uses). No matter how big a dialog with warnings you put, some users will still end up installing things from untrusted sources. We will hold off on a final decision until we discuss how AppCenter will work exactly.
Update: For further discussion of the "Don't Support Installing Debs by Default" topic, check out this Journal entry.
Wow, I'm a bit blown away by the amount of discussion going on here. Awesome!
In case you missed it, I've written an editorial focusing on the installation of apps; check it out here:
http://elementaryos.org/journal/taking-look-app-installation
How come the fullscreen thing will be toggleable, but installing debs won't? I don't feel like carrying my pc tower downstairs to the modem just to install broadcom drivers.
If you have some technical thing you need like that, you can drop to the command line to easily install a .deb. The idea is that we'd be preventing non-technical users from potentially installing random .debs without realizing what they are.
Ok, this debate has gone on for quite a while, so here's my final comment: suppose I'm a developer who wants to get my application into elementary (HIG-compliant and all). Can I be assured that it will get there in a timely manner? Ubuntu is a huge project that's better funded and supported; yet, getting an application into the USC without a push from people in high places is a dreadful chore. Does the team promise a smooth process for getting new applications to elementary OS users? Will the team be packaging all applications that go into this AppCentre (I believe that is what it's going to be called; good luck with Apple's lawyers)?
Just to be clear, we're talking 100% speculation. At the moment, we don't host our own software repositories. We use Ubuntu's. So as of right now, we can't promise anything that isn't already provided by Canonical.
In the future, I think we would all like to have our own repository. But just like everything else we do, it'll be volunteer and community driven. So can we guarantee anything about it at all? No. But as always, we'll try our best.
I highly doubt we'll be packaging things for developers. Instead, we'll probably focus on making the packaging process easier for developers and providing the necessary documentation. Every step that we have do is going to make the process take longer. Ideally a developer will have their software already packaged in their own PPA where we can easily test it for security and QA.
Call it debate or discussion; either way, it's awesome to get this much chatter and interest in our blueprints, and it's always great to hear from our users
"[S]uppose I'm a developer who wants to get my application into elementary (HIG-compliant and all). Can I be assured that it will get there in a timely manner?"
While we still have to work out the details, the short answer is yes. If the app is HIG-compliant and high-quality, I'd expect to see it in the AppCenter right away.
"Does the team promise a smooth process for getting new applications to elementary OS users?"
Again, still working on the details, but it's planned to have an apps repository that will be pulled into AppCenter.
"Will the team be packaging all applications that go into this AppCentre?"
I do believe we will have a packaging team that ensures everything builds and installs properly, then pushes the packages into the repository for AppCenter. I'm not 100% familiar with the packaging process, but I think that constitutes as us packaging it.
I made a guide on how to integrate Firefox 3.6 with elementary os:
http://megatechtoday.blogspot.com/2011/10/how-to-integrate-firefox-36-wi...
Thanks to: http://seahorsepip.deviantart.com/
He said that the one for the newer version Firefox is still not done.
Still waiting for that one...
Its doesn't look integrated to me. Almost, but some widgets don't look like their gtk counterpart.
Many people have already said this in the comments, just want to add my voice. I feel removing the ability to install .deb's is a bad idea. I like, recommend, and use elementaryos because it is simple, intuitive, and clean not because it is super secure or idiot proof. It would be more "elementary" to make the system easier to use not more difficult.
That said this could be handled well. For example: If, when clicking a .deb, I'm prompted with a link that will enable my system to install the .deb then I see no problem. A step has been added, so it'll take one or two clicks more, but it is still just as simple. I do not think installing a .deb should require special knowledge or command line skill. I should not have to "sudo apt-get install *" or 'just know' about a setting buried somewhere amongst a thousand others to enable basic behavior. Make a button that flips the switch and adds the package during the install process for a .deb. Make me read a warning before I click the button, just don't make it artificially difficult in order to push users to use the system how "you" think is best.
(for that extra little bit of security require an admin to make the change. make two buttons, one that turns it on globally from that moment on in perpetuity, and one button that installs gdebi, then installs the .deb, then removes gdebi only allowing the .deb to be installed for that single instance. If the system really is more secure not allowing .debs then this would return it to its default secure state. If the system is just more secure not allowing users to install non-vetted software and gdebi is not a security hole....go get an iphone! : )
Let's look at another point: e-dev team supposes that every user comes from Ubuntu land. But there will be people from Fedora, Slackware, even Windows too! These people will know the danger of installing untrusted software, but probably won't know that gdebi or whatever handles installing local packages. Googling "How to install deb elementary" will leave every person with bad taste in his mouth. You don't want to make a user feel dumb just because he/she wasn't using "The Right OS". Warnings are warnings. Ignore them, it's your fault. If somebody complains that certain deb broke his PC, you can say "We told 'ya!".
"...removing the ability to install .deb's is a bad idea."
We are not removing the ability to install them, just not catering toward that potentially insecure and unsupported installation method. If a user still wants to do it, they can use a dedicated tool like GDebi, or they can use the command line.
"...when clicking a .deb, I'm prompted with a link that will enable my system to install the .deb..."
This is more similar to how Android handles it, which works alright since it's a mobile platform and users don't handle downloaded files as much as on a desktop platform. However, it still has issues. Most of the malware that ends up on Android is only possible because users click through all the warnings to enable this insecure installation.
"Make me read a warning before I click the button..."
Like I allude to above, the problem with that approach is that users become so used to clicking "OK" on any window that pops up that it will simply become ineffective.
In the HIG, it says, "Using specific action names will make it harder for a user to select an unintended action and may even encourage them to read the information presented before making a selection." Maybe this approach can be followed so as not to throw out the baby with the bathwater :)
That doesn't really help. Making the button say "Install" doesn't really enforce the warning.
Just because a "new" or "normal" user wouldn't need to install debs anyway, why would you restrict it?
Because we're targeted at primarily newer or normal users, and non-new or non-normal users can manually enable it if they understand the security implications.
But the problem is the new users. They won't know how to install a .deb if they need.
I think you're missing the point. New users shouldn't need to install a .deb file. Again, I'll point to Android. Sure, not every single app available on Android is available in the Android Market, but new and normal users should go there for their apps. More technical, advanced, or experienced users can dig into the settings and enable installation from .apk files. But new users don't need to know how to install an .apk, nor do they even need to know what an .apk is.
You should also hide gcc from the repositories so new users won't accidentally install it and accidentally compile any software.
But yeah, if you can enable it relatively easily (in Switchboard?), it's fine.
In other commentaries there're good examples of situations that new users need to install debs. Again: this is a desktop operating system, not a smartphone one. There're things that people need to do in their computers, you can't put limits in things you don't know if a user will need or not.
Here's how to make Google Chrome/Chromium fit elementary os' style:
http://megatechtoday.blogspot.com/2011/10/how-to-integrate-google-chrome...
And here's the guide for Firefox:
http://browse.deviantart.com/?qh=§ion=&q=firefox+jupiter#/d3ckwgh
It's far more convincing than Chromium :)
I find this better though:
http://seahorsepip.deviantart.com/art/eFirefox-v1-2-8-181926233
Looks more compact and neat! :D
There is any plan to port Plank in gtk3? It's also in gtk2
Actually there is a gtk3 development branch for Plank waiting for merging into the main Docky branch!
https://code.launchpad.net/~docky-core/plank/gtk3
Reading through these comments, I find it quite admirable how many people stick up for the mythical "normal user," "newbie," "new user," etc. It only proves how much we all want desktop Linux, in some form or another, to succeed. All this talk about the user-to-be, however, is speculative and based on our own bias. While we may have had first-hand experience seeing our friends wrecking havoc on their computer's system files, the only real way to determine what a "new user" will do or be unable to do is to have them sit at the computer and play with it. I think this is one of the reasons Linux ISN'T succeeding; everyone seems to have opinions about what the average user thinks and wants and does, but no one is willing to conduct tests to seek the truth in the matter.
So what's my suggestion? Hand over your elementary-infused machine to your friends to let them check their email, browse the web, play music, etc. and record your observations. Not exactly the most sophisticated study, but it's certainly more helpful than trying to predict their behavior.
I totally agree with your suggestion, it's a great idea and probably the best way to find out. I do see a flaw though. Most usability tests don't require a new user to setup their own system or use it for months at a time. Requiring the ability to install debs isn't something frequent enough to test for in a quick usability test. GUI alterations are easier to test that way and some usability tests would really be good I think.
I do disagree with your assessment of the "new user" though. At one point we were all new users, and for me that meant learning the ropes all on my own. It was an extremely frustrating process. I didn't know anyone who used Linux or even knew a thing about it. I had no outside resources to draw from and more than once I needed to install debs for something relatively simple. Until a couple years ago I had no clue how to add repositories, compile things, or even use the command line. What I could do, was install a deb... simply by double clicking. I will tell you right now, if it hadn't been that simple I would not have hung around, I would've stopped using Linux years ago. As far as things hiding and confusing me, that was never really much of a problem. I have encountered older users however that have had issues with similar things, which is why usability tests would help.
The problem there is that you were required to add repositories and manually install packages rather than having a nice front-end for easy and simple installations. Desktop Linux as a whole is a ton more user-friendly now, and elementary is pushing that even farther.
Also you will probably never hear this again, but my first intro to Linux was actually through the version of Mandriva (Think it was actually Mandrake 7.0) that was sold at Wal-Mart years ago. I passed it in the software section and thought, what the heck I'll give it a go. It didn't last long (maybe a week). I quickly got frustrated and it was years before I decided to try again on a Debian based distro.
I wrote like a ton of comments yesterday, can't someone from the dev team please provide any respons? :)
CassidyJames? Can you please provide some kind of acknowledgement that you've read my rant about window management on the second page of these comments?
I've made my way through all the comments and many people have replied. The threading stops at a certain point, though (otherwise replies to replies to replies to replies to replies to replies would be about a centimeter wide on your screen!). So check the comments that show up below yours for the responses.
for those guys who are complaining about the removal of gdebi, here's something for you to try:
sudo dpkg -i
Would a new user know how to do that??
Would a new user need to install packages manually?
No, they should not need to install packages manually. That's the point. ;)
You don't know that.
The only .deb that i have installed manually was virtualbox. But only because I accidentally learned how to add repos by terminal. New users don't know about sudo add-apt-repository!
All they would need to learn is that .debs are equivalent to exe files. That's much faster than having to learn a terminal.
More like MSI files. They can be harmful to a system and require root privileges to install.
Except they're not equivalent to exe files. An exe on windows is simply an executable, not necessarily an installer. A deb is an installer that requires root access and could be a huge security risk if the user doesn't understand it.
I wouldn't say I'm opposed to hiding WingPanel, but I would say I'm concerned. There are three reasons:
1. On my desktop I have a large monitor, and thus ample real estate, but for aesthetic reasons I prefer to keep plank hidden and on the left. From the notes above, it appears that hiding will be an all or nothing affair ("both Plank and WingPanel always do the same thing."). This means I have to chose between obtrusive plank, or hiding all my indicators. I'm tempted to label this #firstworldproblems — but that's a choice I'd rather not have to make. Best practice, I believe, would be to allow 3 options: Both persistent, both intellihide, plank intellihide. I've excluded WingPanel intellihide as a standalone option because it seems unlikely that someone would choose to always display a 48px panel while hiding a 24px one.
2. I'm still concerned about behavior with multiple apps. Say I have a text editor open for taking notes, and my browser open playing the video about which I'm taking notes. Normally I'd maximize my browser window, then hover the un-maximized text editor window over it. How does the intellihide wingpanel behave? Does it hover over the browser's title bar, blocking the page title and window controls? Does the browser respond by fitting itself into the slightly smaller box? Does WingPanel stay hidden?
3. Probably the most minor concern, but a real annoyance none-the-less. Maximizing a window hides WingPanel, but also places the window control buttons very close to the edge of the screen, which triggers WingPanel to slide down over the window's title bar — and thus the window controls. This is a cat-and-mouse game that I experience too often already with an intellihide dock — and one I'd rather not add to the oft-used window controls.
1. It sounds like you're concerned about your non-default setup. If you're moving docks around and using it in a way it wasn't provided, I assume you're smart enough to change a setting to make them not hide if that's what you'd like to do.
2. We don't know yet; that's something we'll have to figure out. Remember these are blueprints, not final in-stone non-reversible decisions.
3. Again, something we'll have to look at and figure out.
Thanks for the response. As to the first issue — hiding both hide or not hide — it's not a matter of finding the setting, since I'm not opposed to the feature being available, it's that the wording in the notes above implies that it's an all-or-nothing deal; as in, if you want Plank to intellihide, then WingPanel will as well. Because of the persistant nature of indicators, and the non-persistant nature of application icons, forcing the top panel to hide along with the dock in all instances seems like a usability faux pas.
I apologize, I suppose the wording is not clear enough. The idea is that they will always act the same by default. But they're both still separate pieces; if you want to configure them to not behave that way, you're free to.
I think a good majority of brand spanking new users will not stray far from the app center, thinking it's the only way to get apps. For more technical users this is simply an unneeded inconvenience. Please mark a fair line between security and ease of use for both of your intended audiences.
Plank's previous is not bad... in fact I like it!
Will that theme still be available?
Any theme you like can still be applied; we're just choosing a default theme to ship. So, yeah, you can still use the old Plank theme if you're so inclined.
:D
Glad to hear that!
Imagine this scenario, I have no internet at home, but I can connect to the internet anywhere else. I have installed elementary OS but I like to try x application. Download the .deb of the application and take it home in a pen drive. I try to install the .deb but elementary tells me to install gdebi from the repository, but I have no internet! and also if I try to install gdebi by .deb, I can not either!
sudo dpkg -i? also, the typical package needs dependencies. lots of dependencies that aren't installed on the system. try using gdebi to install all of those dependencies. and then what happens when you see a circular dependency (build-essential has a bunch of them). End result: use sudo dpkg -i (drag files here).
That's a wrong approach. Copying over .debs produces such a dependency hell that you'll never want to deal with it more than 1 time. You should use http://keryxproject.org/ instead.