Re: Scroll to zoom in/out.
On 04/14/2010 07:58 PM, Jason Sauders wrote: (In response to comment below) I absolutely positively agree. Gnome Shell is a fantastic thing, and I can see it going far. Out of all of the users I have shown Gnome Shell to and have used it for an extensive period (in the dozens) I can chop a few fingers off and still count on 1 hand how many believed it didn't need a more practical window switcher. Gnome Shell in its current state, to me, feels like it' s a puzzle. A really, awesome, elaborate puzzle. But there's a piece missing right in the center of it, making it difficult to look at and see the full picture. A native window/application switcher -on-the-screen- is what's missing in my opinion. YES - We can take Gnome Shell and install Docky. But I'm a realist... telling people that is going to cause a -1 reputation to Gnome Shell right off the bat. It should feel complimented in every angle. If you don't agree with me, you have nothing to worry about because Gnome Shell currently suits YOU then. I'm speaking on behalf of the majority of users I've spoken to who also agreed with me that there's that ONE piece still missing... Just my 2 cents. Take it for what it's worth. Rovanion Luckey wrote: Just one more thing: GNOME Shell doesn't need a dock, never will, and if you want a different way to access your applications, just use a dock yourself or wait until someone develops an add-on for A similar feature. We do not want to create the shell as a product that when it is out, people will talk about it in terms of: Yes gnome shell is wicked cool! You just have to add a dock for window switching and then it is totally awesome!. Gnome Shell should be released as a finished product, not something where the general consensus is that you have to change and add a lot of stuff to get it working. It should simply work. -- www.twitter.com/Rovanionhttp://www.twitter.com/Rovanion ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list Yeah, I couldn't agree more. Some UI element is sorely needed that can allow a user to quickly switch between open windows and/or running applications without the screen changing or having to remember a key combination. The user should technically not have to every use the non-mouse hand for simple tasks IMHO. The overview is a great concept in many regards, and I think it should stay, but after using GNOME Shell for a couple weeks now I have to say that, like it or not, it needs something as a window list. I have 3 Firefox windows open and 2 terminals on 2 desktops- with the overview all the Firefox and all the terminals look identical. I have to mouse over each one to get to what I am looking for. That's not very efficient at all, and quite frankly I am finding it frustrating to the point of considering discontinuing it's use. In other words, it's getting in my way. A lot. I would hate to see what this does for a novice. Another thing that you have to realize is that by activating the overview, you change the appearance of the entire screen, which can be very confusing sometimes. The change in the entire visual appearance, with windows moving around to order then back again, leaves the user lost sometimes. I feel like I never know where things are. I get that there are people here that don't like window lists or taskbar type UI elements, but Alt-tab and picking the app or mousing over multiple windows in the overview does not add to efficiency in my opinion. Everything else, however, is quite fantastic :) ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Finding and Reminding, tech issues, 3.0 and beyond
On Wed, 2010-04-14 at 18:04 +0100, Martyn Russell wrote: On 14/04/10 16:10, Alexander Larsson wrote: On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor wrote: User defined tags A completely flat view of all documents doesn't handle all users or use cases. Frequent filers will want to be able to identify projects and other subsets of files. There's not a detailed plan for the user interface right now, but technically this could be done a couple of ways. We could use the traditional method of grouping by using folders; and just make that look somewhat tag-like in the UI. (Make selecting a folder show all the files in that folder and all sub-folders. Allow creating a folder of files without worrying where it was and automatically creating it in ~/Documents.) Or we could use a real tag-based approach with tags stored in metadata. (multiple tags per file, tags orthogonal to folders.) Does tracker currently index gvfs/gio metadata? No. Since all writes to metadata goes through a centralized daemon it should be very easy to tell tracker about changes, and the format is designed so it should be very efficient to index. I've always planned to add support for this, but its not yet happened. That sounds quite similar to what Tracker does, perhaps not as efficient of course (due to infrastructure/IPC/etc). GVfs metadata is also structured to be very efficient for the typical access patterns of file i/o (enumerated all files in a directory with metadata, most consecutive i/o done in the same directory, etc) by grouping per-directory data together, using mmap to allow efficient in-process caching of data, allows sync operations that are efficient, etc. This leads to very high performance for the typical gio operations. Tracker instead has a more general database which is much better for more complex lookups (like searches or reverse indexing) but is overkill for directory structured accesses. What about files which are not copied/moved/etc with GIO APIs/commands? Obviously the metadata won't follow these changes, but thats the case with any lookaside storage for metadata, and even for xattr for any operation but rename on same filesystem. Even a save new copy of doc operation will lose xattrs if done using write-to-temp-and-rename-over if the saving code doesn't do extra manual work to keep them. And xattrs are still prohibitly slow, see the comments in the blog post i linked to. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Window management pie menu
Good day, I have an idea to present that I would like to call the PieThrower. The idea resolvs around providing the user with an easy and fast interface to throw application windows to different workspaces. The inspiration came from this very mailing list. Basically the discussion went around adding buttons to the window list. Either many buttons representing each direction to which a window could go or one button spawning a secondary menu showing one button for each currently existing workspace. While these designs solve the issue they either clutter the window border in a way that might seem too much or they are based on two a two step menu with small icons. What the PieThrower bases around is the concept of the user throwing or sending windows to other workspaces with the use of a pie or circle menu, depending on what you like to call it. A pie menu is a menu shaped as a circle with one slice for each option. There are two ways as I see it that this interface could be accessed, either by a button located on window border or when the middle mouse button is pressed on the border. When the user triggers interface a pie or circle menu appears showing one piece for each one of maximally four directions possible. The menu is spawned around the mouse or button location and the different are activated either by mouse position or release of the mouse button. To break up the preceding wall of text and further explain the design, here is the PieThrower spawned by a button when three other workspaces are open to the left, to the right and underneath: i296.photobucket.com/albums/mm167/Rovanion/ButtonMockup.jpg?t=1271184688 This pie menu in this mockup is spawned by a button. In this case the user can either press the button, then release the mouse again, and then press the slice he or she wishes to. But this is not the most efficient way to go. Pressing the button, but never releasing it brings up the menu just as fast. Now there are two different ways to go here. One where a slice is activated when the user releases his mouse on or outside of a slice. The inner circle always cancels the menu. The other where activation of a slice happends either when the user releases his mouse on a slice or directly when the mouse reaches outside of a slice. This second option is the one that would give a real edge to the function making it feel as if you were throwing the window to your next workspace. Here is a second mockup spawned from middle mouse button showing a usecase where Gnome Shell is sorting the workspaces in linear view. Here the user has one workspace open to the left but none to the right, but the interface allows for the user to open up a new workspace and send the window to it: i296.photobucket.com/albums/mm167/Rovanion/ButtonMockup2.jpg?t=1271184731 http://i296.photobucket.com/albums/mm167/Rovanion/ButtonMockup2.jpg?t=1271184731So after this throw at explaining the PieThrower I would like to ask the code writers who managed to read through the whole idea, is this possible to do? And if it is possible to realize this idea, what happens next? PS: The same design could be used to switch workspaces, middle click background or other suitable area and off you go. -- www.twitter.com/ http://www.twitter.com/RovanionRovanion ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Do/not implement Dock.
Dnia 2010-04-15, czw o godzinie 00:59 -0600, Sean Brady pisze: I have 3 Firefox windows open and 2 terminals on 2 desktops- with the overview all the Firefox and all the terminals look identical. I have to mouse over each one to get to what I am looking for. That's not very efficient at all, and quite frankly I am finding it frustrating to the point of considering discontinuing it's use. I would argue that 3 identical firefox icons and 2 identical terminal icons are even less distinguishable. This is one of the usability failures of Dock I already mentioned. With overview, you see window contents and can easily pick the one you're interested in. It's exactly the window you want and remember - just smaller. Another thing that you have to realize is that by activating the overview, you change the appearance of the entire screen, which can be very confusing sometimes. The change in the entire visual appearance, with windows moving around to order then back again, leaves the user lost sometimes. I feel like I never know where things are. That's why the transitions are animated. Every window is animated from the point it originally was and shrunk to the overview position, and grew back when you leave the overview. This keeps spatial connections and is designed to work with human brain cognitive abilities. Maybe your gfx card is not able to handle the transition well, and everything just jumps from place to place for you? I see very smooth window transitions on Intel G31. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Scroll to zoom in/out.
On 04/14/2010 09:29 AM, Rovanion Luckey wrote: I don't understand why everyone wants to run GNOME Shell with a dock. It clutters up your screen, uses a lot of memory (especially Docky), and it just isn't necessary at all. First you make the statement that a Dock is in no way needed. I admit, Iamusing a dock right now, but it's DockBarX, so it sits on my panel while giving me that awesome program grouping that docks give you in a much more compact way. Then you go ahead and tell us that you do indeed use a dock, not the Docky that youdespisebut another dock. Besides of visual and some very minorfunctionaldifferences these two applications are the same to the user. They are designed around the same concept and fill the exact same need. They are docks, the names of the applications indicates that enough. I personally think of it as a "more compact on-panel application switcher". I guess my definition of dock is a little different than yours. Second, I'm only using this dock in GNOME 2. I don't need it in GNOME Shell because of how it's designed. Now this is not a discussion suitable for this mailing list so I will stop at that. I didn't exactly want it to continue either, to be honest. I wanted to point out how GNOME Shell is just fine without a dock and doesn't need one. It groups programs in the overlay and it would be redundant to have that feature in more than one place. GNOME 2 doesn't have the overlay, so thus I use DockBarX. Just one more thing: GNOME Shell doesn't need a dock, never will, and if you want a different way to access your applications, just use a dock yourself or wait until someone develops an add-on for A similar feature. We do not want to create the shell as a product that when it is out, people will talk about it in terms of: "Yes gnome shell is wicked cool! You just have to add a dock for window switching and then it is totally awesome!". Gnome Shell should be released as a finished product, not something where the general consensus is that you have to change and add a lot of stuff to get it working. It should simply work. I think you mis-interpreted what I said there. There are lots of people that use Firefox, for example, mainly because of its add-ons/plugins. On its own, without any add-ons at all, Firefox is a great, stable, and fast program that shows how great free-as-in-freedom software can be. The developers of course realize that they aren't perfect and they never will be, so they let people change the program to fit their needs/wants. Personally I'd be using Chromium, Opera, or something similar right now if I wasn't able to customize my browsing experience to fit my needs (tree style tab, ad blocking, script blocking, cookie blocking, read-it-later, etc.) The main reason I use GNOME and similar desktop environments is because they not only make it easy to "jump in and go" without needing to configure anything. But the thing is, GNOME is simply a "desktop environment"; just a framework for how we use our computer. If there's some minor detail or feature that GNOME does not provide that some people (thought not necessarily everyone) would like, like a dock-style mechanism for switching applications, we can't say "no you can't do that" because we can't stop them. If the dock add-on is good, very good, it might even lead more people to use GNOME Shell. I do agree with you that we should try our very best to make GNOME Shell readily usable (and I love it how it is right now), but like Firefox, we shouldn't tell people that they shouldn't "do their own thing". This is one of the reasons I moved to Linux: we're "free" over here to do things with our system that Apple/Microsoft won't let us do, mainly because it "isn't our system" if we used their OS's. For example, the CSS customization of GNOME Shell, or the panel applets in GNOME 2. Iapologiseif this email was interpreted as aggressive towards you Ryan Peters, it was notmeantas such. 'Tis fine, none taken. I just hope I don't seem like I'm mad at you :). Sorry for sounding rather... "noob-ish"? Is the correct word? ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Scroll to zoom in/out.
On 04/14/2010 08:57 AM, Tomasz Sterna wrote: Dnia 2010-04-14, śro o godzinie 08:35 -0500, Ryan Peters pisze: GNOME Shell doesn't need a dock, never will, and if you want a different way to access your applications, just use a dock yourself or wait until someone develops an add-on for A similar feature. By the way, can't you switch applications with the sidebar? *psst, whoever is working on that sidebar, I hate how it pushes everything over; I wish it was more auto-hide-y* There is no sidebar in current Gnome Shell anymore. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list That's odd; seems to be working on my laptop. Maybe I'm just on an old build. Nevermind! ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window management pie menu
On 04/15/2010 07:40 AM, Rovanion Luckey wrote: Good day, I have an idea to present that I would like to call the PieThrower. The idea resolvs around providing the user with an easy and fast interface to "throw" application windows to different workspaces. The inspiration came from this very mailing list.Basically the discussion went around adding buttons to the window list. Either many buttonsrepresenting each direction to which a window could go or one button spawning a secondarymenu showing one button for each currently existing workspace. While these designs solve the issue they either clutter the window border in a way that might seem too much or they are based on two a two step menu with small icons. What the PieThrower bases around is the concept of the user throwing or sending windows to other workspaces with the use of a pie or circle menu, depending on what you like to call it. A pie menu is a menu shaped as a circle with one slice for each option. There are two ways as I see it that this interface could be accessed, either by a button located on window border or when the middle mouse button is pressed on the border.When the user triggers interface a pie or circle menu appears showing onepiecefor each one of maximally four directions possible. The menu is spawned around the mouse or button location and the different are activated either by mouse position or release of the mouse button. To break up the preceding wall of text and further explain the design, here is the PieThrower spawned by a button when three other workspaces are open to the left, to the right and underneath: i296.photobucket.com/albums/mm167/Rovanion/ButtonMockup.jpg?t=1271184688 This pie menu in this mockup is spawned by a button. In this case the user can either press the button, then release the mouse again, and then press the slice he or she wishes to. But this is not the mostefficientway to go. Pressing the button, but never releasing it brings up the menu just as fast. Now there are two different ways to go here. One where a slice is activated when the user releases his mouse on or outside of a slice. The inner circle always cancels the menu. The other where activation of a slice happends either when the user releases his mouse on a slice or directly when the mouse reaches outside of a slice.This second option is the one that would give a real edge to the function making it feel as if you were throwing the window to your next workspace. Here is a second mockup spawned from middle mouse button showing a usecase where Gnome Shell is sorting the workspaces in linear view. Here the user has one workspace open to the left but none to the right, but the interface allows for the user to open up a new workspace and send the window to it: i296.photobucket.com/albums/mm167/Rovanion/ButtonMockup2.jpg?t=1271184731 So after this throw at explaining the PieThrower I would like to ask the code writers who managed to read through the whole idea, is this possible to do?And if it is possible to realize this idea, whathappensnext? PS: The same design could be used to switch workspaces, middle click background or other suitable area and off you go. -- www.twitter.com/Rovanion ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list Love it! This makes sense, as it more easily exposes the idea of switching workspaces and doesn't require going to the overlay or using some kind of keyboard shortcut. I hope something similar to this is implemented in the future! ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Finding and Reminding, tech issues, 3.0 and beyond
On Thu, 2010-04-15 at 13:05 +0100, Martyn Russell wrote: On 15/04/10 12:32, Bastien Nocera wrote: On Mon, 2010-04-12 at 11:31 +0100, Martyn Russell wrote: On 10/04/10 22:10, Owen Taylor wrote: On Sat, 2010-04-10 at 11:43 -0400, Jamie McCracken wrote: On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor wrote: Well, certainly tracking and indexing file metadata doesn't *require* anything as complex, or general purpose as RDF. I have some concerns about the complexity, but as long as we don't get to the point where understanding RDF and ontologies is a prerequisite for developing a GNOME app, we're probably fine. I don't think this is such a bad thing. What other choices are there? understanding how to extract the metadata from a specific file yourself or understanding SQL to talk directly to a database? At least SPARQL is something in between which provides the right level of power without exposing the DB. And it ends up being neither. If you're manipulating file formats you understand, or if you understand the concepts and a library does the work for you, you're better off extracting the metadata yourself. Are you? So if you have more than one application interested in the same data, that's still better off? Plus what about the implementation, is it better to have n ways to extract the same data each one more/less featured/erroneous to the next or one place which does it and is maintained? My point was that SPARQL is neither a well-targeted API like that of a library, nor is it SQL (which people know, and hate), but somewhere in between. It's neither, and that means that you need to learn a new query language. snip I couldn't this time last year either (and that's not a benchmark for how long it takes to learn either). I don't think your case is a good one, given that you worked on Tracker almost exclusively during that time. Better come up with good documentation before offering it to developers. Well, other than the online docs we are constantly improving: http://library.gnome.org/devel/ontology/unstable/ Huh. Go to that page, and find me the ontology that pertains to media, or contacts. The big picture is actually unreadable on my big (1680x1050) screen. There is also the actual standard we try to follow: http://www.semanticdesktop.org/ontologies/ At least that page has the TLAs exploded, and has more details about what each ontology does. Maybe it would be better to format this in gtk-doc style to replace the one on library.gnome.org. If you're used to RDF of SQL, SPARQL isn't so difficult. There are also examples on the live.gnome.org wiki: http://live.gnome.org/Tracker/Documentation/Examples Those seem like magic recipes. Again, it might be useful to have those available as helper functions, so they have vouched for and tested as part of your test suite. Plus our code base is riddled with examples which have to work. In addition to all this, we are on IRC to help too. Bastien, if you think something else is missing, please tell us and we will try to fix it. Am I allowed to extend ontologies? What's the process for that? What happens if I want to store private data (something not covered by the existing ontology, say, the ASIN or MusicBrainz ID for music)? What pitfalls should I look for when I create queries? How do I deal with escaping in those queries? Where do I find information about the big picture of how all those things work together. Apple has a nice introduction that could be used as an example of what I would be expecting: http://developer.apple.com/mac/library/documentation/Carbon/Conceptual/MetadataIntro/MetadataIntro.html Cheers ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Finding and Reminding, tech issues, 3.0 and beyond
On Thu, 2010-04-15 at 10:34 -0400, Jamie McCracken wrote: Is it entirely true that RDF/Sparql, whilst giving us the power to model stuff better, is harder to use and makes things more difficult to devs who dont know it I had always imagined there would be a client library that did not expose RDF/SParql which would allow for more simple use and queries (query by example or some simpler language). It would be much more limiting than pure sparql but for the majority of apps where metadata use is one dimensional it would suffice. However it would be wrong to scrap RDF/Sparql as you could not model links between resources nor interact as well with non-file cloud based data. Also by utilising nepomuk ontology, we are benefiting from the large EU investment in it and the refinements from Nokia/KDE which ensure the ontology is application driven and not purely theoretical in nature The apple metadata spec is one dimensional and could not be extrapolated easily to model more sophisticated ontologies. Tracker 0.6 metadata was like apples and it proved insufficient for the needs of Nokia and Nepomuk You completely missed the point. I never said that Apple's metadata spec was good, I said their docs were. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Do/not implement Dock.
2010/4/15 Tomasz Sterna to...@xiaoka.com Dnia 2010-04-15, czw o godzinie 08:44 -0400, Mark Curtis pisze: But Sean is commenting on how they all look similar IN THE OVERVIEW. Let's test it: http://codex.xiaoka.com/~smoku/tmp/GnomeShell.png 3 Opera windows, 2 terminal windows. EASILY recognisable in a snap! I cant see how three Firefox Windows could look exactly the same in the Overview, besides having the exact same Site open three Times (like 3 Google Instances) which usually happens...uhm never? Please, Gnome Shell is about creating something thats supposed to guide us into the future of DE's. So whats the sense in including Gimmicks that fruity company invented what, like 10 years ago? Usability first, EyeCandy later... And now please dont think i dont know how useful things like Docky or AWN appear to be, i've tested both for quite some time and keep doing so with every significant change to those Apps, but are they really necessary on a Day to Day Base? Me thinks not ;) ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
RE: Do/not implement Dock.
Usability first, EyeCandy later... EXACTLY!! People like myself,Sean Brady, and the countless other people that have commented on this whenever this sort of thread pops up in the mailing list, feel the way you switch apps now in GNOME shell IS A USABILITY ISSUE, that needs to be fixed. The only mouse driven way to switch currently is via the overlay, which arguably is more eye candy than usability. I've pointed out how it's more mouse movement (compared to the 2.X window list) and the buttons are smaller (compared to the 2.X window list). but are they really necessary on a Day to Day Base? Me thinks not ;) I don't use accessibility features on a day to day base, guess that means no one else does and therefore GNOME Shell shouldn't use it. I don't like this title Do/not implement Dock I mean, I personally would like SOME SORT of window switcher, even if it weren't specifically a dock. I loved the idea of breadcrumbs, but the GNOME devs would rather just waste the space right of the Activities menu to show you the active application and maybe some mysterious 'menu' if they ever get around to it. Date: Thu, 15 Apr 2010 17:26:30 +0200 Subject: Re: Do/not implement Dock. From: cldx3...@googlemail.com To: to...@xiaoka.com CC: gnome-shell-list@gnome.org 2010/4/15 Tomasz Sterna to...@xiaoka.com Dnia 2010-04-15, czw o godzinie 08:44 -0400, Mark Curtis pisze: But Sean is commenting on how they all look similar IN THE OVERVIEW. Let's test it: http://codex.xiaoka.com/~smoku/tmp/GnomeShell.png 3 Opera windows, 2 terminal windows. EASILY recognisable in a snap! I cant see how three Firefox Windows could look exactly the same in the Overview, besides having the exact same Site open three Times (like 3 Google Instances) which usually happens...uhm never? Please, Gnome Shell is about creating something thats supposed to guide us into the future of DE's. So whats the sense in including Gimmicks that fruity company invented what, like 10 years ago? Usability first, EyeCandy later... And now please dont think i dont know how useful things like Docky or AWN appear to be, i've tested both for quite some time and keep doing so with every significant change to those Apps, but are they really necessary on a Day to Day Base? Me thinks not ;) _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Tiny application buttons again (was: Do/not implement Dock.)
On Thu, Apr 15, 2010 at 8:35 AM, Mark Curtis merkin...@hotmail.com wrote: Usability first, EyeCandy later... EXACTLY!! People like myself,Sean Brady, and the countless other people that have commented on this whenever this sort of thread pops up in the mailing list, feel the way you switch apps now in GNOME shell IS A USABILITY ISSUE, that needs to be fixed. The only mouse driven way to switch currently is via the overlay, which arguably is more eye candy than usability. I've pointed out how it's more mouse movement (compared to the 2.X window list) and the buttons are smaller (compared to the 2.X window list). I feel I should jump to the buttons being smaller there. Just think what could be done with those application entries if they had more space! New Window could be a primary function instead of something that must be accessed through a context menu (which limits the feature's user base to about six people). The application title could be big; there could be an actual textual description of what it is doing. Just imagine the possibilities! Meanwhile, that Documents list is enormous. I'm wondering if that list taking up half the screen actually makes it more useful. Has anyone tried listing just items from the past two days (taking queues from Zeitgeist's activity journal) and using, maybe, half the space? And on the original topic, here's Apple's Exposé: http://en.wikipedia.org/wiki/File:Expose_in_spaces.png Note that the windows are not strictly tiled, but positioned in an efficient way that moves them as little as possible. There is probably an idea or two to be gained from there. I loved the idea of breadcrumbs, but the GNOME devs would rather just waste the space right of the Activities menu to show you the active application and maybe some mysterious 'menu' if they ever get around to it. For the application menu part, is it possible to borrow the Application Indicator spec? It's used downstream in Ubuntu, and KDE is pretty cool with it as well. https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators If the top right is reserved for specific system stuff, those other buttons should go _somewhere_ and that may be a good opportunity. Dylan ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
RE: Application menu / switcher
Subject: Application menu / switcher From: to...@xiaoka.com To: gnome-shell-list@gnome.org Date: Thu, 15 Apr 2010 18:04:17 +0200 Dnia 2010-04-15, czw o godzinie 11:35 -0400, Mark Curtis pisze: but are they really necessary on a Day to Day Base? Me thinks not ;) I don't use accessibility features on a day to day base, guess that means no one else does and therefore GNOME Shell shouldn't use it. If you need accessibility features - you turn it on. If you need dock - you install it. Turning on an included feature is not the same as installing it from somewhere else I don't like this title Do/not implement Dock I mean, I personally would like SOME SORT of window switcher, even if it weren't specifically a dock. This is exactly what I'm advocating for. We should come up with a nice design for a fast applications switcher, not mindlessly copy-paste dock/taskbar because everyone else uses it. Oh, okay so we're on the same page then? Having some application switcher. I loved the idea of breadcrumbs, but the GNOME devs would rather just waste the space right of the Activities menu to show you the active application and maybe some mysterious 'menu' if they ever get around to it. That's just unfair. You shouldn't bash developers, because they did not implement a planned feature yet. Please be constructive and encouraging. GTK+ already has infrastructure for removing the application from its menu. See: http://code.google.com/p/gnome2-globalmenu/ I think it should be integrated in GnomeShell. The way I see it: http://codex.xiaoka.com/~smoku/tmp/app_menu_mockup.png (a bit crude but I'm no artist) Yea I apologize that was a bit unfair. I guess I'm just disappointed that the area could be used for something, it's currently not. There is something the devs have planned, but I'm not clear on what it is or when, so as of right now it's wasted space. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window management pie menu
2010/4/15 Kaj-Ivar van der Wijst kaj-i...@vanderwijst.com Thanks for the good idea. I really like the concept. However, this isn't very useful when there are three or more desktops in linear view. Does anyone has other ideas to solve this issue? You could instead of arrows have each workspace represented by their number, and require the user to press the button of the workspace they want to send the window too. But that would break the design. Instead of being an absolute nobrainer where the users drag in the direction they want it becomes a complex menu where the user has to think, now where did I want that application to go? That is a complex menu like the rightclick menu, and by the way, I really like the looks of your right-click menu Thorsten Wilms. The PieThrower is a very simple design that allows the user to without having to think more about it get that window to another workspace. More complex operations take more time and there is already an interface for these more time-consuming operations, both trough the right-click menu and the Activities overlay. -- www.twitter.com/Rovanion ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window management pie menu
I really like the looks of your right-click menu Thorsten Wilms. +1 Thanks for the good idea. I really like the concept. However, this isn't very useful when there are three or more desktops in linear view. Does anyone has other ideas to solve this issue? You could instead of arrows have each workspace represented by their number, and require the user to press the button of the workspace they want to send the window too. This could be hidden from the user so that it doesn't clutter the view, but if they happen to know the workspace they want to send it to, they could press the number (on the keyboard) when PieThrower is open and the window would be sent to that workspace. We could also add a second level to the PieThrower with a double arrow that moves the window by two (or more) workspaces (if there are enough workspaces in that direction). Since this would only be visible when the user has enough workspaces open, it would stay out of the way of most people, keeping it as simple and clean as possible. Thoughts? ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: One-click window switcher.
2010/4/15 Tomasz Sterna to...@xiaoka.com: The problem is: Current Gnome Shell lacks one-click active window switcher. Let's think how could we solve it. Actually you can switch windows with only one click; the Activities button features a hot corner so you don't need to click on it. Personally I would like to see minimized windows on the desktop But that'd still require some way to make the desktop visible, wouldn't it? If so, does this mean that the problem is not that you have to go to the overlay, but that the animation happening when the overlay shows up is annoying? -- Siegfried-Angel Gevatter Pujals (RainCT) Free Software Developer 363DEAE3 ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Finding and Reminding, tech issues, 3.0 and beyond
(Replying selectively - lots of stuff snipped that I agree with) On Tue, 2010-04-13 at 21:18 -0500, Federico Mena Quintero wrote: On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor wrote: I've attempted below to extract out some of the technical bits from http://live.gnome.org/GnomeShell/Design/Whiteboards/FindingAndReminding This is great stuff. I feel kind of bad commenting from the sidelines, given that I have done practically no work on gnome-activity-journal or the Zeitgeist engine, but anyway, here goes. Basically, the FindingAndReminding page has come to conclusions that are very similar to what gnome-activity-journal tries to be. In this mail I want to convince you that g-a-j plus Zeitgeist are the right way to go for GNOME, and that reimplementing them would be a waste of resources. [...] User defined tags A completely flat view of all documents doesn't handle all users or use cases. Frequent filers will want to be able to identify projects and other subsets of files. Yeah, we need to show tags as something more than this file has such and such tags and this is a search query for tags. When I was thinking about the Journal two GUADECs ago, I imagined that you could be able to circle a bunch of files and tag them visually. Imagine taking a red pencil, circling a few events in the journal, and giving them a purple tag that says Research Paper on Monkeys. The purple tag appears somewhere prominent (current projects? recent tags?) so you can access those items again easily without scrolling back in the timeline. Firefox's recent tags command is incredibly useful- this is more or less the same. One of the things on the Wiki view that I didn't comment on here - because I didn't have much of an idea of how we would do it - was What if similar or related items were automatically stacked together so they don't clutter the Desktop? In some cases, we should be able to figure out relatedness without the user being involved - if I view a bunch of images in a directory in a row, we may want what we show the directory rather than the images as the toplevel history item. But at other times, we need user input, and that user input is usually after the fact - asking users to come up with tags as they save documents isn't enough. [ Though I think what would be very cool from a file save dialog with tagging support is that if you entered a new tag, it gave you the ability also to add that tag to some of your recent files. ] Lots of UI work to figure this part out, hopefully largely independent of the backend, except for the low-level details of tag storage. Timeline view of files Clearly we agree on this :) One thing I like about the mockup in the FindingAndReminding page is that the items are laid out in a grid. Imagine this: [ ] [ thumb ] File with a long descriptive name.odt [ ] [thumb] [thumb] [thumb] [...] (imported 234 photos) [ ] [ thumb ] Another file with a meaningful name.pdf [ ] I.e. an irregular grid. You don't want to show meaningless names like dsc02345.jpg for photos, but you do want document titles or descriptive filenames when they are available. You may want bigger thumbnails of PDFs than of photos so that they are easier to recognize. Sounds neat. And hard. [...] Adding non-files to Desktop Good. Zeitgeist supports this, and is one of the more interesting features. I'd add these to the timeline: - Web pages, or those that you bookmark. - Mails that I sent. - Mails that I received that have attachments. - Attachments that I saved. - IM conversations that I had. - Handwritten notes (Tomboy in the journal) - Files or items that I can drop into future dates. - Git pushes. - With help from Greasemonkey or whatever, google docs that I edited. I think this is something a little different than what I was talking about. The Desktop is the set of things that is immediately available - current and future items - and is separate from the timeline view of past items. Some of the items you list above (web page bookmarks, notes, emails you received, etc), do make sense on the desktop, but I don't think you'd want, to say, drag a Git push to the desktop. [...] The only think I can think of in the current mockups that requires a Zeitgeist-like approach is the Frequent selector. Without a longitudinal view of usage, it's hard to answer what are the most frequently used documents in the last 30 days. One really interesting aspect of Zeitgeist is the data-mining algorithms it uses to present items that are frequently used together - the Apriori algorithm and such. I wouldn't want to lose this. One thing that would make the timeline really useful would be to split the screen in two, with the timeline on one side and the related items in the other side. I'm going to be up-front and express some skepticism about
Re: Window management pie menu
Dnia 2010-04-15, czw o godzinie 18:20 +0200, Rovanion Luckey pisze: Thanks for the good idea. I really like the concept. However, this isn't very useful when there are three or more desktops in linear view. Does anyone has other ideas to solve this issue? You could instead of arrows have each workspace represented by their number, and require the user to press the button of the workspace they want to send the window too. Maybe: - if you quickly drag to the button or click it, you move the window to the next workspace - if you drag and hold the mouse over the pie button not releasing the button, miniatures of all desktops in that direction unfold and you may drop the window on the selected desktop ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Application menu / switcher
BIG BIG BIG plus +1 on the idea from Tomasz Sterna!! This: http://codex.xiaoka.com/~smoku/tmp/app_menu_mockup.png http://codex.xiaoka.com/%7Esmoku/tmp/app_menu_mockup.png is the way to go! I was just typing a long winded response advocating doing exactly this. I actually already sent a long winded advocacy note for doing this, see: mail.gnome.org/archives/gnome-shell-list/2010-April/msg0.html No one seemed that interested though. (Its not exactly the same thing as the mock-up here, but same idea) And I thought there was already something filed on Bugzilla for a right click of the App Title in the panel to bring up a window list. Can't find it now though. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
New grid layout with Up/Down
Hi everybody,
I'm trying to modify the js files so to have working CtrlAlt Up /
Down to switch between up/down layouts as well.
I managed to change between workspaces :
...
... and here a piece of the part of windowManager.js :
...
workspaceDown: function(currentIndex) {
let N = global.screen.n_workspaces;
switch(currentIndex) {
case 0 : return N 2 ? 2 : 0;
case 1 : return N 3 ? 3 : 1;
case 2 : return N 6 ? 6 : 0;
case 3 : return N 7 ? 7 : 1;
case 4 : return N 5 ? 5 : 4;
case 5 : return N 8 ? 8 : 4;
case 6 : return N 12 ? 12 : 0;
case 7 : return N 13 ? 13 : 1;
case 8 : return N 14 ? 14 : 4;
case 9 : return N 10 ? 10 : 9;
case 10 : return N 11 ? 11 : 9;
case 11 : return N 15 ? 15 : 9;
case 12 : return 0;
case 13 : return 1;
case 14 : return 4;
case 15 : return 9;
}
return currentIndex;
},
actionMoveWorkspaceDown: function() {
let newIndex =
this.workspaceDown(global.screen.get_active_workspace_index());
global.screen.get_workspace_by_index(newIndex).activate(global.get_current_time());
if (!Main.overview.visible)
this._workspaceSwitcherPopup.display(WorkspaceSwitcherPopup.DOWN,
newIndex);
}
(ok, this is a dirty hack since it only works up to 16 workspaces...)
but well, even if I could get a better way to find the top/down
neighboring workspace, this would'nt fix all problems I have.
1.
get_workspace_by_index(newIndex).activate(...); does the workspace
switching. Sadly, I couldn't even find it.
I suppose it is some kind of signal since the Workspace object doesn't
have an activate function (but there's an addSignals on it,
then...).
Is it the case ?
What is added to Workspace then ?
2.
And how can I change the workspace switching behaviour ?
Because now, it is switching to the correct workspace, but in an
horizontal manner which looks really bad since I'd like to switch from a
cell to a vertical neighbor in this case.
3.
I added images and the css binding to them in workspaceSwitcherPopup.js.
It is great. Except for the current layout (St.BoxLayout) which isn't
what I want.
I'd like to use something like a St.Table (looks like it exists
according to gnome-shell sources).
But I really don't know how to find informations about those kind of
objects. How do core and gnome-shell native things get imported ?
const imports.gi.St is what ? some js file I couldn't find ?
Where can I found it to know how to use it and St.BoxLayout and / or
St.Table if there is one ?
I suppose it gets translated into something related to gnome-shell C
code for there are similar things in gnome-shell source code
(st-boxlayout, workspace, screen ...).
And there are many imports which don't have their js corresponding file
(I'd like to know how to use things in my js-hacked files).
All imports.ui.* stuff seems to be pseudo-javascript and present in
share/gnome-shell/js/ui, but the other like imports.gi.* ... where are
they ???
Is there information about how to customize the pseudo-js things ? Now
I'm trying by intuition. But I'm missing some good documentation about
how things get really translated, where are imported / importable
things, what to do with them...)
Or maybe it is present in the sources and I missed it ?
Thanks for you help
Alexandre Kaspar
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window management pie menu
I believe that the suggestion is for moving windows quickly out of the current workspace. For organizing windows if a situation where there are many workspaces (i.e. moving a window two workspaces down), the overview should be used. A pie menu would be an addition to the current interface, allowing the user to quickly setting aside windows without disturbing the workflow. On Apr 15, 2010, at 10:42 AM, Kaj-Ivar van der Wijst kaj-i...@vanderwijst.com wrote: Hi, Thanks for the good idea. I really like the concept. However, this isn't very useful when there are three or more desktops in linear view. Does anyone has other ideas to solve this issue? But in general, the idea is great! Best regards, Kaj-Ivar Op 15-04-10 15:41, Ryan Peters schreef: On 04/15/2010 07:40 AM, Rovanion Luckey wrote: Good day, I have an idea to present that I would like to call the PieThrower. The idea resolvs around providing the user with an easy and fast interface to throw application windows to different workspaces. The inspiration came from this very mailing list. Basically the discussion went around adding buttons to the window list. Either many buttons representing each direction to which a window could go or one button spawning a secondary menu showing one button for each currently existing workspace. While these designs solve the issue they either clutter the window border in a way that might seem too much or they are based on two a two step menu with small icons. What the PieThrower bases around is the concept of the user throwing or sending windows to other workspaces with the use of a pie or circle menu, depending on what you like to call it. A pie menu is a menu shaped as a circle with one slice for each option. There are two ways as I see it that this interface could be accessed, either by a button located on window border or when the middle mouse button is pressed on the border. When the user triggers interface a pie or circle menu appears showing one piece for each one of maximally four directions possible. The menu is spawned around the mouse or button location and the different are activated either by mouse position or release of the mouse button. To break up the preceding wall of text and further explain the design, here is the PieThrower spawned by a button when three other workspaces are open to the left, to the right and underneath: i296.photobucket.com/albums/mm167/Rovanion/ButtonMockup.jpg?t=1271184688 This pie menu in this mockup is spawned by a button. In this case the user can either press the button, then release the mouse again, and then press the slice he or she wishes to. But this is not the most efficient way to go. Pressing the button, but never releasing it brings up the menu just as fast. Now there are two different ways to go here. One where a slice is activated when the user releases his mouse on or outside of a slice. The inner circle always cancels the menu. The other where activation of a slice happends either when the user releases his mouse on a slice or directly when the mouse reaches outside of a slice. This second option is the one that would give a real edge to the function making it feel as if you were throwing the window to your next workspace. Here is a second mockup spawned from middle mouse button showing a usecase where Gnome Shell is sorting the workspaces in linear view. Here the user has one workspace open to the left but none to the right, but the interface allows for the user to open up a new workspace and send the window to it: i296.photobucket.com/albums/mm167/Rovanion/ButtonMockup2.jpg?t=1271184731 So after this throw at explaining the PieThrower I would like to ask the code writers who managed to read through the whole idea, is this possible to do? And if it is possible to realize this idea, what happens next? PS: The same design could be used to switch workspaces, middle click background or other suitable area and off you go. -- www.twitter.com/Rovanion ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list Love it! This makes sense, as it more easily exposes the idea of switching workspaces and doesn't require going to the overlay or using some kind of keyboard shortcut. I hope something similar to this is implemented in the future! ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window management pie menu
If you really needed to place the window on a specific workspace, then you should use the overview. If we add this functionality to the pie menu, we would sacrifice the ability to throw widows out of the way, and I believe that is the main benefit of such a menu-it allows users to quckly set aside windows without breaking their workflow. Just my two cents. On Apr 15, 2010, at 2:36 PM, Tomasz Sterna to...@xiaoka.com wrote: Dnia 2010-04-15, czw o godzinie 18:20 +0200, Rovanion Luckey pisze: Thanks for the good idea. I really like the concept. However, this isn't very useful when there are three or more desktops in linear view. Does anyone has other ideas to solve this issue? You could instead of arrows have each workspace represented by their number, and require the user to press the button of the workspace they want to send the window too. Maybe: - if you quickly drag to the button or click it, you move the window to the next workspace - if you drag and hold the mouse over the pie button not releasing the button, miniatures of all desktops in that direction unfold and you may drop the window on the selected desktop ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: One-click window switcher.
The problem with switching windows through the overlay is that it floods the user with all sorts of information, thus breaking the workflow. Swithcing windows shouldn't involve breaking the workflow. On Apr 15, 2010, at 12:54 PM, Siegfried-A. Gevatter siggi.gevat...@gmail.com wrote: 2010/4/15 Tomasz Sterna to...@xiaoka.com: The problem is: Current Gnome Shell lacks one-click active window switcher. Let's think how could we solve it. Actually you can switch windows with only one click; the Activities button features a hot corner so you don't need to click on it. Personally I would like to see minimized windows on the desktop But that'd still require some way to make the desktop visible, wouldn't it? If so, does this mean that the problem is not that you have to go to the overlay, but that the animation happening when the overlay shows up is annoying? -- Siegfried-Angel Gevatter Pujals (RainCT) Free Software Developer 363DEAE3 ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Finding and Reminding, tech issues, 3.0 and beyond
There has been discussion here about making the desktop just another view for recent/relavant files. However, I believe this can be extended to include a view of the Task Pooper. Basically, the Desktop would have two sections: - Things that I have been doing recently - Things that I plan to do. The first of these sections would show recent/relavant files. The second part would be a larger display of the Task Pooper: It would show all the tasks that the user has planned to do, separated by the time frame the user planned to do them in: ie, today, tomorrow, etc. Items that deserve attention could be highlighted on the desktop, thus helping the user stay on task, by reminding the user what needs to be done. Furthermore, the desktop view of the Task Pooper would allow dragging and dropping as well, so the user could drop things to do onto it as well. When something is being dragged, a placeholder icon could appear in the task pooper section of the desktop, with the text Drop Things here to make it a task (or something to the same effect). Finally, when the task pooper is empty, the desktop view could show the same text at all times, thus introducing the user to the task pooper feature. I think this would make the desktop a great tool for *reminding* users about the tasks that they plan to do on the computer, and keep files that need to be worked on easy to access. Just a suggestion. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Fwd: Window management pie menu
Sorry, I forgot to reply to all -- Forwarded message -- From: Apoorva Sharma appi2...@gmail.com Date: Thu, Apr 15, 2010 at 9:16 PM Subject: Re: Window management pie menu To: Tomasz Sterna to...@xiaoka.com On Thu, Apr 15, 2010 at 6:30 PM, Tomasz Sterna to...@xiaoka.com wrote: This is covered by first use case. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list Then there would have to be a time based delay, and thus it would be in the users best interest just to go to the overview. However, I wouldn't mind having this feature -- just another way to interact with the windows in Gnome Shell. This PieThrower is a really neat idea, and I would really like for it to be implemented. -- appi ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
