- Journal
- Council Notes: Sept 24, 2011
Council Notes: Sept 24, 2011
Submitted by cassidyjames on Mon, 09/26/2011 - 19:03The Council meeting on Saturday was a short sweet one in which we mostly discussed some Launchpad blueprints. Let's take a look at these blueprints and some things we wanted to point out.
Blueprints
The following blueprints were presented and discussed. If you have feedback, please write it on the blueprint's whiteboard.
Intellihide for Wingpanel?
When a user maximizes an app, they're trying to make it as big as possible, using the most available space. Currently, however, the panel and dock remain in the way of this supposedly "maximized" application.
Maximizing should make the dock and panel slide away to give the app the most room available. This is already somewhat possible with Plank's intellihide setting, but there is no such option for WingPanel at this point in time.
This blueprint proposes that WingPanel would gain an intellihide option, or would at least hide when the focused window is maximized. The rationale is that when a user is maximizing an app, they're wanting it to take up the screen, giving them as much room to work in the app as possible. They are doing it intentionally and for that sole purpose. Hiding the panel gives them even more room inside their app. In addition, the sliding animation would indicate that the panel was hiding away up top, plus the user can easily undo their action in the same way they did it in the first place (clicking the maximize button on the top-right of the window).
If you have feedback for this blueprint, feel free to write on the whiteboard here.
Next sprint: Contractor?
For a really integrated desktop we need to make non-elementary apps support Contractor.
If the apps will show Contractor button only when Contractor is present in the system, such patches can be merged upstream (unlike AppMenu, adding search boxes, etc)
This blueprint proposes holding a developer sprint for Contractor. As a Council, we discussed whether or not we'd like to push it as the next sprint. We are still undecided on whether we'd like to do this or a more user-facing app first. If you have feedback, feel free to write on the whiteboard here.
Fix up non-default apps?
Some people might install apps that don't integrate with the environment well by default (chromium, firefox, etc). It might be a good idea to ship tweaks and fixes for those apps with the OS to make them integrate better once they are installed.
This blueprint proposes creating and shipping customizations, fixes, or tweaks to apps we don't officially support or include with elementary. This could help make these apps integrate better with elementary. The general feeling is to not include the tweaks with elementary, but if tweaks do exist, to make them easily installable. If you have feedback, hit up the whiteboard here.
Non-traditional filesystem?
Ala Gobolinux and Moon OS, elementary should use a custom filesystem hierarchy. One that is more friendly and logical to any new or returning Linux users.
It would mean that the folder layout from the root onwards would be completely different to the standard Linux distribution. But if done in a thoughtful way it can make the new and old users life easier.For example, if looking for the themes folder a user could now find it in the root of the filesystem under: /themes. As opposed to: /usr/share/themes.
This can be done for many other folders, the least of which would be the users home folder which could be relocated say to the root of the filesystem under: /users.
The surprising thing is, you can still install and use these distro's as any other, due to symbolic linking of the old filesystem hierarchy.
For easier reference (as it has not yet been named) I'll call it: Logical Filsystem Organisation. LFO, for short.Here is some documentation with a better explanation and the implications:
http://www.gobolinux.org/?page=faq
http://www.gobolinux.org/?page=at_a_glance
This blueprint proposes using a more logical (and less traditional) filesystem. This would make the filesystem more sensible for average users, and should still make installing legacy/traditional applications work seamlessly. If you have feedback, please share it on the blueprint's whiteboard.
Ksplice
We can use ksplice, to upgrade the linux kernel, without having to restart the PC to take effect.
Ksplice has its own update dialog.
This blueprint proposes using a technology called ksplice to prevent system upgrades from requiring a restart. This could mean users actually never have to restart their elementary machines while still receiving and applying all the security updates. If you have feedback, please drop it on the whiteboard here.
Decisions
Video Tutorials: We've decided we will revive the video tutorials effort for the launch of elementary OS Luna. This will help new and prospective users see how easy elementary OS from right on the elementary website.
Let us know what you think of the blueprints and decision above by sharing in the comments!
I think the title bar is a waste of space not the panel. The panel is the center of all interaction within applications.
If we hide it, we can't have notifications disappear as you might miss them. I also don't like the idea of icons coming from the bottom, as you might start something by accident, right when it appears.
In my opinion, this would only add unneeded clutter and complicate things.
If you guys need more space, hide the title bar in maximized windows. I always maximize most windows, and it is not bad as some people argue. The screen is for content not for wallpaper. And having the wing panel auto hide is a show stopper for me.
It's not that we "need more space," but that we want to improve the experience of using maximized apps. If a notification came in while an app is maximized, it'd a.) most likely have a notification bubble to tell you about it, and b.) make the offscreen panel glow (just like how the offscreen dock glows when an icon wants your attention).
In another vein, could the site developers please include a Journal RSS feed?
It's been implemented as a standard RSS feed pretty much since the site was redesigned. If your browser detects RSS feeds (most do), it'll appear either in the location bar or the menus. If it doesn't, here's the link: http://elementaryos.org/journal/rss.xml
I'm excited for the video tutorials section, presuming I'm envisioning it properly... I'm interested in putting elementary OS on the PCs of my non-technical-user friends as a means to give them a solid, user-friendly computing experience that will also be debian-derived for easy maintenance on my end should they have problems. This seems like it would ease that transition.
Thanks very much!
Here's a thought. Why use Midori? It's just not good enough. Slow, buggy and feature-poor. Why not just use Firefox? FF7 is blazing fast, the best browser in the world, and based on this theme (http://zeeeeee.deviantart.com/art/Jupiter-Firefox-0-6-202529105?q=boost%...), it's clear that FF can be made to follow the elementary theme. All that remains is overlay scrollbar support, but that should land in Ubuntu some time, so you could just use that :)
Never. Gonna. Happen.
We only ship 100% native applications. And especially for the default apps, it's really important that they are specifically designed for elementary. Firefox is a cross-platform app, which means it's not even designed for Linux in general. It uses the slow and bloated XUL toolkit instead of native GTK. It doesn't follow our HIG, and there's nothing we can do about it. It's not realistic for us to work with Firefox upstream. We'd have to maintain a bunch of patches, there'd be another theme for me to maintain, it's just a lot of work with no real reward.
If you're having a problem with Midori's speed, it's not Midori it's your webkit version. Try upgrading to the latest release. Midori has always been faster than even Chromium in my experience. If you're encountering bugs, make sure to file them in launchpad. Every release does contain bug fixes. If you're missing a feature, either file a bug report or write an extension. Midori supports extensions written in Vala or C.
The best part about shipping Midori is that it's lead developer is a member of our council. So that means we have a huge influence over the direction that it takes. Just wait until you see the Midori that lands in Luna. There's a lot of really cool stuff coming down the pipes that'll make you wonder why you ever thought it was a good idea for us to use anything else.
Midori for me! I like it very much. It has a simple design and is very fast. It will also have some improvement before Luna so that is good
I am against Wingpanel intellihide as well. It doesn't take much space compared with the dock anyways.
First, it's not traditional intellihide where it'd slide away any time a window is nearby, but it *only* hides as a result of an explicit action; maximizing/fullscreening the window.
Second, it's not solely about the number of pixels, but about focus. By explicitly telling the app to go fullscreen, you're saying you want to focus on that window. The panel and its indicators become secondary, so they get out of your way.
Don't worry; we'll be working hard at making everything as seamless and perfectly-implemented as possible. :D
I like most of the ideas, but the Wingpanel intellihide. I suppose I'll have to wait to Luna to try it if it gets approved to see if it's useful to me. If not, I would love an option to disable it.
Keep up the good work!
I'm glad you're open to trying it; we think you'll love it. There will likely be a setting to disable the hide-on-maximize. Of course, if you don't like WingPanel at all, you can always swap it out with a similar application; Pantheon is inherently modular. :)
Please dont spread misinformation! With the gobolinux kernel module for the filesystem hierarchy there is ONE command, to turn it on or, so that you can switch to the old one if you like, and back of course!
EDITED BY A MOD
Hey, watch your language! http://elementaryos.org/code-of-conduct
That sounds really goog because I don't like the idea of the new filesystem.
I think it would be an excellent idea to have autohide for Wingpanel BUT have it as an option that the user can turn on or off from Switchboard. If the user wants it he can have it or if the user doent want it he can disable it
I'm a little late with my comment, but I feel as though the automatic hiding of WingPanel on maximized window is generally a good idea that requires very smooth execution. If it were my decision, I would maintain an easy way to traditional-maximize an application ALONG WITH a user-friendly way to "fullscreen" an application. One way of doing this would be to have the traditional maximize action continue to be triggered by the maximize button, whereas "fullscreening" an app would require the user to drag the title bar of a particular application to the top of the screen.
I always felt that Ubuntu and Window's 7 inclusion of both of these methods of maximization was repetitive -- why have two mouse-driven ways to do the same thing? And as a user of a 10-inch netbook, screen real estate IS at a premium, and I appreciate all the work elementary Devs are putting in to aid users like me.
If you change the filesystem hierarchy, all these tutorials for ubuntu about tweaking the system and stuff won't work. And maybe there will also be some software incompatibilities as well.
It's best not to touch it, in my opinion.
The great thing is that it would *not* break things. The FS change would be done through symbolic links - so if you type, for example: cd /usr/share, it will change to that directory properly. There would be no software incompatibilities. :)
Why don't elementary hide wingpanel by default, and have a plug in switchboard were users are able to choose settings for the wingpanel. Choose if the wingpanel is hidden or not, or how it should react.
Wonderful discussion, folks. Lots of passion for the distro, here. :D
Thinking... Instead of intellihide or something similar, what about hidding the dock and wingpanel *only* when a window is maximized? (both always shown [not intellihide] when a window is umaximized). I think that would be a simpler and more predictable behavior for a new user. When windows are unmaximized, both dock and wingpanel should be always visible. When you want more space, you maximize the window and then wingpanel and dock disapear. This alternative is more touchscreen-friendly. In a touch device, for example, a gesture for revealing both wingpanel and dock could be implemented. Also posted on blueprint.
I posted my thoughts on the blueprint as well. :P
But yeah, that'd be the ideal case. That way maximizing the window makes it take all the space, but it wouldn't hide simply by putting a window close to it.
LFO is a great idea! I've been hoping for a long time that more distros would pick it up. It doesn't seem like it would be to hard to ask the user if they would like to use this option or not during install, but doesn't that also mean (since they are symbolic links) that you can just browse the file system in the old way just as easily? "The surprising thing is, you can still install and use these distro's as any other, due to symbolic linking of the old filesystem hierarchy. "The surprising thing is, you can still install and use these distro's as any other, due to symbolic linking of the old filesystem hierarchy." So why not use it? I would love to have this available.
Intellihide for panels? AWESOME!
Ksplice? EVEN BETTER!
I believe the symlinking is done invisibly. So you don't actually see the symlinks, but if an app goes to install something in a "traditional" place, it gets installed in the proper place. And vice versa for opening files.
Intellihide is a good idea, but should not be ON by default. Indeed it uses too much _horizontal_ space. There's too much black that does nothing. The overlapping panel (the original design) is much better, but it's kinda weird for new user, so if you ever decide to implement it, add a "Trim" option, and make it OFF by default.
elementary-tweaks is a good idea, but shouldn't it be a meta package?
Ksplice is cool. Please think about a rolling release cycle too.
Regarding rolling release: If I'm not mistaken, all the different parts that make up elementary will be modular enough that they can be laid on top of any Linux distribution, including those with rolling release schedules like Arch. I wouldn't be surprised to see a community effort on this once things really start coming together.
If you are thinking about the space for the maximized windows maybe you should think about something that will hide the top bar as well. and put only the Close Minimize and Maximize in the wing panel with intellihide. The good thing in this will be that you don`t really need a bar for the menu as we have all the menu in the settings button. And you don`t need to put even the name of the program that is running cause since you`ve maximized that window you know why have you maximized it in the first place.
Those would be some nice options in the elementary-tweaks:P
Control buttons on wingpanel? No thanks. Indeed it could save place, but looks ugly. Full screen is sufficient.
Ok. That would be kinda weird. Another option will be to add a button next to the settings one. Maybe it`s just me, but the top bar should not be there in the maximized window.
Yeah, I think if it were ever done, it wouldn't be an official project that we include by default, but more of a metapackage that users can install. Though maybe it would make more sense to have a package for each app's tweaks. So firefox-elementary-tweaks, transmission-elementary-tweaks, etc.
After get used to the standard Linux FS, and having to learn another one seems so annoying more then making it easier. Please have some option keep the current one. Like the hide for wingpanel but needs to be turned off by default.
Regarding the filesystem, it would seriously take about 30 seconds to "learn." The whole idea is that it's simpler and makes a whole lot of more sense from the human perspective. If elementary adopted an alternative filesystem, simply "keeping the current one" wouldn't be possible nor feasible, unless the user compiled their own kernel (which goes against everything elementary is).
*agrees with cassidy*
Not only it is fast to learn for those that already know, it is so much easier for newcomers... so yeah, makes sense to change.
I do rather like the idea of intellihide for wingpanel, although I think it should be optional and that it should default to off if I'm honest.
I am a little perplexed as to the justification used though. For me, the loss of vertical space is a minor consideration compared to violation of Fitt's law with respect to window controls. I've always thought that positioning wingpanel along the bottom, and the dock along the top edge, would be more consistent with Fitt's law. I can see a justification for maintaining indicators along the top edge (as in my experience the top edge is line-of-sight) but I'd be willing to forgo that nicety as long as notify-osd bubbles still appear in the top-right corner.
I also somewhat like the simplified file-system approach, as long as symbolic linking enables 'compatibility' with the standard Linux file-system hierarchy. Would it also be possible to disable the simplified file-system view (via GSettings for example?), as whilst I understand the utility of a simplified file-system view for layman I rather like the status quo.
I'd love to see a contractor sprint! It seems attracting attention to some of the underlying technology (like contractor) should take precedence in the early stages. It'd be nice to see contractor support extended to non-standard applications (Firefox, Thunderbird, etc...) to showcase the technology to a wider audience.
As much as I like many non-core elementary applications (Firefox, Thunderbird, Transmission, Empathy, etc...) I do think that a formal developer commitment to them would be asking a bit too much. I would appreciate the efforts of a few hobbyists/enthusiasts in this area though, and I'm sure as elementaryOS becomes more popular this will happen naturally anyway (as wonderful as elementary core applications are, some will inevitably prefer non-core applications and seek to integrate them visually and technically).
There are some great thoughts here! Thanks for taking the time to share.
I believe if it were done, it'd only happen on maximizing/fullscreening an app. If we have to program something then disable it by default, it almost seems counterproductive to program it at all. ;) But yeah, for it to happen, it'd need to be very slick and obvious.
Accessing the indicators and apps are two very common behaviors. Also, both of which are nondestructive. Closing a window, however, is considered "destructive" (or potentially so), so it's not important that Fitt's Law applies. It's arguably important that Fitt's Law doesn't apply so the user doesn't accidentally close the window.
Interesting ideas. I'm not sure how that'd work with the dock ontop, obscuring things and whatnot. I'm interested in a mockup. :D The problem with moving the indicators away but leaving the notification bubbles in the same spot is that they're connected; a notification bubble appears, prompting you to interact with it through the indicators, which are right above.
Yes, the technology would retain compatibility with the traditional file structure. However, I believe the hiding of the symlinked directories is done at the kernel level, making it impossible to simply "switch off" unless you use an alternate kernel compiled without the module.
I think we all agree that the sprint needs to happen. :D And yes, I agree that it should happen in the early stages. It's just determining whether or not we have a different app that needs attention.
This is where I stand as well. I don't think any official effort should be spent on apps we don't preinclude or at least recommend. But yeah, if an enthusiast or whoever wanted to contribute, we could maybe consider including them in our repos.
"If we have to program something then disable it by default, it almost seems counterproductive to program it at all. ;)"
^ this is a major problem. You have to offer people choice. If this is the attitude to features and settings, then your philosophy essentially becomes "my way or the highway".
I definitely have to agree with Cassidy here. There is no point in putting in the effort to build something if we don't plan for people to use it.
No we don't really have to offer choice at all. I think we're pretty set on only offering an option where it really makes sense. And really, I think most people don't have a problem with this as long as the defaults are sane.
About "Intellihide for Wingpanel?"
I think it is more logical to integrate the title bar. Instead of hiding Wingpanel.
But if Wingpanel adds intellihide, I hope there will be an option to turn it off. I just need a clock on my screen 24/7, otherwise I always forget the time.
Hi, i agree with you, intellihide will be "disturbing" for the clock. We need a clock displayed permanently !
ps: @ elementary team if you make video tutorials, i'll help you to make french subtitles. And what about creencasts that will teach basics of the elementary platform ? Just like GNOME Screencasts Episode but with elementary tools, this could be usefull.
Right? I'm all for minimalism but having a hidden clock... hmm...
I don't care about hiding everything else, I just can't be left clockless xD (most of the time).
I agree with those who say that intellihide on Wingpanel is a bad idea. Wingpanels contain INDICATORS, and their basic function dictates that they be visible at all times to indicate. If there is a counter that should anything require your attention, Wingpanel will slide back into view: well, that's annoying. I think Wingpanel should just slide OVER the window decorations (remove or change the positioning of the fullscreen icon currently on the right, and replace Applications/Places/System with a consolidated Slingshot). That would be an effective use of space.
Wingpanel wouldn't necessarily have to slide in to view in order to show that something needs attention. We could use the same method as Docky/Plank of showing a glow coming from offscreen.
Just about everything that Wingpanel indicates is either something that you (the user) dictate, such as volume level, online status, etc. or it's something you get a notify-osd notification about when it changes, like your network connection status, or a new message. So really in all honesty, I'm not sure you really *need* to have the indicators shown at all times.
We've already had our fair share of good times dealing with problems caused by trying to put the panel over the window decoration. That's not really an acceptable solution.
By the way, I've been thinking of the dock as a place to hold app-specific, not system-wide notifications (like new mail).
But there's a known issue with Ubuntu notifications - you surely miss them if you're afk. GNOME Shell suffers this too, despite having a notification queue. DockManager badges are a great replacement for a notification queue as it's seen in GNOME Shell (Ubuntu lacks it at all, if you don't count messaging menu), but still suffer the AFK problem.
Making an off-screen flash for each email or IM message you get is an overkill, so I propose the following: when the number in DockManager badge increases, half of the icon holding the badge should pop out at the bottom even if the dock is hidden. Once I open the dock and the dock hides back, the badge hides too, because I've already acknowledged that I'm here and I've seen the notification. This way I'll never miss AFK messages and we don't make up a notification queue as a separate entity.
Thoughts?
Really love your idea for the dock icons. Obvious, but also ignorable if you are busy and need to concentrate on something else until you are ready to check the notification.
I take it it wouldn't do this for fullscreen apps though (like games)?
OSX keeps bouncing applications until you check them. Awn does that too. It works fine but I think your approach is much less obnoxious and much more direct. The dock should also reset to hidden if you alt-tab to the application (even if you don't read the e-mail/etc).
Yeeeeaaaaah, I love the idea of offscreen glowy notifications when I have an app maximized/fullscreened. :D
I think there should be two options: maximized and fullscreen. Fullscreen will hide the panel, maximized will not.
I think hidding wingpanel is not necessary. It creates confusion, and as dannyboiii said, new users freak out when the "main system panel" disappear. If you implement it, please don't enable it by default... Except if the solution adopted is very very creative... But think about it. Hidding a ~30px panel doesn't make a real difference even for small screens. The top panel is used by new users as a "landmark" for being oriented of where they are all the time.
I'm in favor of a "fullscreen button" (instead of a maximize button), like the MacOS X one, even, instead of hidding and unhidding things. Less confusive and helps to focus on your task. But please, don't take the same direction as Ubuntu.
The change in filesystem sounds very good. But it has to be with extreme precaution. It has to be very self-consistent.
The hiding isn't just for pixels, but for focus. If a user wants to maximize their app, they are wanting to make it take up all the space so they can focus on it and it alone.