Re: [Ayatana] Overlay-scrolbar in Dash
On Sat, Oct 1, 2011 at 9:39 PM, Pierre-Olivier Megret pomeg...@yahoo.fr wrote: Hello Everybody It's my first post here. So i hope you will excuse my english. unfortunately , I'm french indeed ;-) . I'm used to read yopu but not to write here. I'm using Ubuntu since Hardy and I've 11.10 on my two Computers since Alpha1. Does everyone know why dash doesn't use Overlay scrollbar? I think white scrollbar is too close from items in current dash and consequently difficult to spot and use ? The dash uses a different widget toolkit to most applications, as such, the scrollbars need to be implemented in that toolkit as well to be usable. That's just a matter of development manpower/time. Thanks ! ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Modal Dialog: Background
To clarify, the intended effect here is to fade to the background color of the window (in this case, darken). It's broken in oneiric however because the gtk theme is missing some elements. On Wed, Jul 6, 2011 at 2:51 AM, Stefanos A. stapos...@gmail.com wrote: Desaturate + darken is the way forward. The white overlay is ugly (plus it's the same effect as stuck applications on Windows) and the blur effect, while nice, hinders usability. 2011/7/5 Marco Biscaro marcobiscaro2...@gmail.com Why don't we go with blur instead? I think that it's because blur is *slow* in a lot of hardwares. If I enable static blur effect for dash, it tooks about 3 or 4 seconds to open. With a maximized window, I think the delay will be noticeable too. Anyway, I agree that this white overlay is ugly... ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana-dev] Breakage with latest compiz
Just so that everyone knows what's going on here 1. There's a bug which I'm currently tracking down in gtk3 where calling gtk_init_check more than once from different dlopen ()'d libraries in certain circumstances will cause gtk to crash 2. Both the unity shell and slate style dialogs plugin require gtk in order to get theme information 3. gtk_init_check must be called at /least/ once before you do that 4. For debugging purposes, either one or both plugins could be enabled 5. We can't call gtk_init_check twice in the case that both are enabled, but we must call it once 6. We can't check if gtk_init_check has been called already by another plugin 7. The interim solution was to make a /new/ plugin which calls gtk_init_check and is loaded first 8. We can't dynamically add depended plugins at runtime (only through ccsm which needs to be fixed in libcompizconfig) 9. People who have changed their settings and then don't enable gtkloader are in for some crashes 10. As such, we're now moving this into a distro-patch in compiz for the time being 11. If you previously had this plugin enabled then you need to disable it since it would cause 1. to happen Thanks everyone and happy upgrading :) On Tue, Jul 5, 2011 at 1:11 AM, Didier Roche didro...@ubuntu.com wrote: Hey everyone, If you run unity from trunk and are using oneiric, you probably enabled a couple of days ago the gtk loader plugin in cssm. If so, ensure to disable it after installing compiz 1:0.9.4+bzr20110606-0ubuntu5 on tonight's upgrade. This one is not needed and wil conficts (you will have the screen frozen). Then, rerunning unity should work again ;) Sorry for the inconvenience, there is no other way for a clean upgrade path for our oneiric user (we can't add plugins dynamically in compiz). Didier __**_ Mailing list: https://launchpad.net/~**ayatana-devhttps://launchpad.net/~ayatana-dev Post to : ayatana-dev@lists.launchpad.**netayatana-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~**ayatana-devhttps://launchpad.net/~ayatana-dev More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana-dev Post to : ayatana-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana-dev More help : https://help.launchpad.net/ListHelp
Re: [Ayatana-dev] Unity build from source error
Oh, that repo is definitely outdated :) use the upstream git://git.compiz.org/compiz/core On Sun, Jul 3, 2011 at 10:58 AM, Abhishek Singh abhishek1...@gmail.comwrote: I used the instructions in the INSTALL file in Unity to install the compiz-core from git://git.compiz.org/users/dbo/compiz-with-glib-mainloopinto /opt/unity is the INSTALL file or the resource outdated? -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana-dev Post to : ayatana-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana-dev More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Two key issues to fix in Unity
On Sun, May 29, 2011 at 1:18 AM, Jo-Erlend Schinstad joerlend.schins...@gmail.com wrote: On 28. mai 2011 04:35, Sam Spilsbury wrote: On Sat, May 28, 2011 at 3:48 AM, Jo-Erlend Schinstad joerlend.schins...@gmail.com wrote: Sorry about the pun, but there are a few keyboard issues that I think requires some attention. 1. If you press super+w (what is that view called?) and then press alt+f2, then you can work with the window without bringing it into the foreground. For instance, I pressed alt+f2, typed a few words and pressed enter. Those words were sent to an IRC channel because Xchat had focus. What on earth is the purpose of that? Sounds like a bug where the application launching lens can receive focus while the workspace switcher is open. File a bug on launchpad with instructions to reproduce. Then you can confirm that it is not an intentional feature that I just don't understand? Yes, mis-matched focus is definitely not a feature ;-) 2. When you press and hold super, then the launcher appears almost immediately. If you hold it another second, then the icons get numbers on them to show what number key to press in order to launch an application or switch to it. My question is: why is there a waiting period before those numbers are displayed? The one second without those numbers doesn't seem to serve any purpose? There is a reason why I think this is important but I'll save that for another post. If you presssuper + num, it launches the application or brings its windows to focus for the number that appears over that launcher icon. Yes, but if you only press super, then the launcher is shown until you either release it or press something else in combination. The question is why the launcher and the switch numbers aren't displayed simultaneous. Why do you have to wait a second after the launcher is displayed before the numbers are displayed on top of the tiles? I think it's to reduce visual clutter, eg, everything happening at the same time when you press super. It basically works like this Tap Super - Launcher shown + Dash appears Press Super (eg, ~ 1 second) - Launcher shown Press and hold Super - Launcher + shortcuts shown. 3. Is there an easy way to find all keyboard combinations in the different modes of Unity? I mean normal desktop, lenses and super+w? Not at the moment. The designers are trying to figure out keyboard shortcuts that are intuitive for everyone so we don't have to ship big manuals with what all the shortcuts do for everyone. If you can think of better ones, please suggest them by all means :) If no good overviews exists, then it is my intention to make one. I didn't join this community out of curiosity. Feel free :) I think someone has already made a guide for where all the keyboard shortcuts are though ... not sure where that is. I have some really good ideas for keyboard bindings. What is the most efficient way to make them very visible to the Unity developers that are working on Compiz stuff? Talk about them here :) Where do I find information about Compiz plugins? I only know a few languages, but if I can contribute with code, then that's certainly what I'm going to do. Compiz is written in C++. You can find the documentation on http://wiki.compiz.org/Development or if there's something that's not explained there you can ask me on #compiz-dev on freenode (I'm smspillaz). Happy Hacking :) Thanks. Jo-Erlend Schinstad ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
[Ayatana-dev] Compiz Community Module Maintainers
Hi everyone, At UDS I discussed the idea of having community module maintainers for the various bits in compiz, so that we can delegate community members who are interested in the vision of one particular module or plugin (or many of them, if they choose) to be the maintainer for it. They will be responsible for developing the code to fit their vision, doing pre-commit code review (another mail coming about that shortly), maintaining the bug list and being the contact person for questions about that module. The reason that I am doing this is because I've found that I've had limited time to be the maintainer of everything and I've found that certain modules are suffering from bitrot because nobody has time to work on them. I think that if nobody has time to work on a module or a plugin or something, it needs to become unsupported and we need to let distributions know about this. However, I believe that to a certain extent, we should have a category for modules where we will at least work to keep them supported with API changes and the like. So here is the deal. 1) All modules will be marked us unmaintained from this point in. If someone wants to claim maintainership of a module, they'll need to post a mail here explaining why they want to be the maintainer for that module and what they think their qualification is for doing so. Note here that since we need maintainers more than anything else right now, I would imagine that the qualification bar here will be quite low for modules that are already effectively unmaintained. 2) There will be certain modules (such as core and plugins main) that I would imagine would have multiple maintainers. In this case, to get code upstream, it needs to be reviewed by ALL the maintainers within some timeframe 3) I'll start by saying that I'll claim maintenance of the stuff in plugins-main and core, subject to whatever that will be (another mail coming about that one shortly). If anybody else wants to claim for that, just send me an email to the list. Furthermore, I'll be starting to reach out to external contributors who might be interested in maintaining various plugins. I think with a more diverse development community focused on the little things Compiz can grow as a project. Regards, Sam -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana-dev Post to : ayatana-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana-dev More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Two key issues to fix in Unity
On Sat, May 28, 2011 at 3:48 AM, Jo-Erlend Schinstad joerlend.schins...@gmail.com wrote: Sorry about the pun, but there are a few keyboard issues that I think requires some attention. 1. If you press super+w (what is that view called?) and then press alt+f2, then you can work with the window without bringing it into the foreground. For instance, I pressed alt+f2, typed a few words and pressed enter. Those words were sent to an IRC channel because Xchat had focus. What on earth is the purpose of that? Sounds like a bug where the application launching lens can receive focus while the workspace switcher is open. File a bug on launchpad with instructions to reproduce. 2. When you press and hold super, then the launcher appears almost immediately. If you hold it another second, then the icons get numbers on them to show what number key to press in order to launch an application or switch to it. My question is: why is there a waiting period before those numbers are displayed? The one second without those numbers doesn't seem to serve any purpose? There is a reason why I think this is important but I'll save that for another post. If you press super + num, it launches the application or brings its windows to focus for the number that appears over that launcher icon. 3. Is there an easy way to find all keyboard combinations in the different modes of Unity? I mean normal desktop, lenses and super+w? Not at the moment. The designers are trying to figure out keyboard shortcuts that are intuitive for everyone so we don't have to ship big manuals with what all the shortcuts do for everyone. If you can think of better ones, please suggest them by all means :) Thanks. Jo-Erlend Schinstad ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana-dev] [Ayatana] Alt Tab User Experience
On Thu, May 26, 2011 at 10:24 AM, Brandon Watkins bwa...@gmail.com wrote: The current alt tab function in ubuntu is quote broken. Minimized windows show as blurry, ugly icons and have no thumbnail. I know this is a known issue, but something needs to be done about this if ubuntu wants a polished user friendly experience. Such a basic function cannot be broken like this. Right. The reason for this is because applications don't provide high resolution thumbnails in their _NET_WM_ICON property. So we have to use the low-res one. I believe that KDE 4 applications provide hi-res icons, and GNOME 3 actually matches the .desktop file to the application. This is something that compiz might do in the future (at least through an external plugin). I have recently used both gnome 3 and kde4 and they both do not have this issue, and have an acceptable alt tabbing experience. Looking at gnome-shell's alt tab is an example of this done right. It helpfully groups programs, has high resolution icons, and thumbnails that work properly. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayat...@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana-dev Post to : ayatana-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana-dev More help : https://help.launchpad.net/ListHelp
[Ayatana] Launcher DnD - import applications on DnD start
Hi there, I was having a quick conversation with a few people about the new launcher DnD behaviour (highlighting applications which can handle the MIME type from the .desktop file). I thought it would be cool to extend this behavior slightly further so that the launcher will import the default application that handles that file type into your launcher if there isn't an application in the launcher that handles that file type. This is useful if, for example, you want to open an image or video file through drag and drop, but don't need to have Eye of GNOME or Totem cluttering up your launcher all the time (since they are primarily view only applications). What does design and Project Ayatana think? Cheers, Sam -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Launcher DnD - import applications on DnD start
On Thu, Feb 10, 2011 at 11:45 PM, Shane Fagan shanepatrickfa...@ubuntu.com wrote: Hey Sam, If I understand you right you want to allow applications to be opened on the file by dragging the file to it then im all for it. This is already implemented. Rather what I was thinking was that if an application that handles that MIME type isn't already in the launcher, then it will be temporarily added to the launcher. It doesnt sound like a whole lot of work to get it working either. --fagan On Thu, 2011-02-10 at 23:26 +0800, Sam Spilsbury wrote: Hi there, I was having a quick conversation with a few people about the new launcher DnD behaviour (highlighting applications which can handle the MIME type from the .desktop file). I thought it would be cool to extend this behavior slightly further so that the launcher will import the default application that handles that file type into your launcher if there isn't an application in the launcher that handles that file type. This is useful if, for example, you want to open an image or video file through drag and drop, but don't need to have Eye of GNOME or Totem cluttering up your launcher all the time (since they are primarily view only applications). What does design and Project Ayatana think? Cheers, Sam -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana-dev] Mentorship, Signal Propagation in Unity
On Wed, Jan 5, 2011 at 12:22 PM, Josh Headapohl joshh...@gmail.com wrote: Yes! I needed to Ungrab the pointer. I get prelighting on the menu items now, without releasing the mouse button, but I still can't make selections. I think this is due partly to some code in QuickListView that checks whether mouse presses are inside the quick list area. How would I debug the Unity plugin? I found the following post (by you ;) ) which says how to start Compiz with gdb, but it looks like I'm restricted to compiz core. http://forum.compiz.org/viewtopic.php?t=11246 It might be that I just don't know how to use gdb very well! I've never used it with a project this complex before. You should just be able to compile the unity plugin with debugging symbols and then do breakpoints wherever (eg break unityshell.cpp:linenumber or Launcher.cpp:linenumber) or on particular functions. gdb will complain about how symbols aren't loaded yet, just ignore this, it will auto-resolve them once they are dlopened. Thanks, Josh On Tue, Jan 4, 2011 at 10:21 PM, Sam Spilsbury smspil...@gmail.com wrote: On Wed, Jan 5, 2011 at 11:05 AM, Josh Headapohl joshh...@gmail.com wrote: Thanks Sam, for replying to my question and for pointing me in the right direction. I didn't see the inheritance structure before and everything makes a little more sense now. You are correct that the code that handles drag events does not look at which button is pressed. The LauncherIcon class does handle clicks and quicklist creation, while drag events are handled by the Launcher class. If I add a check in the Launcher class to consider which button is pressed, I can prevent the right mouse button from initiating drags. Cool, that's part one at least Unfortunately, whether or not the launcher icon is dragged, if the mouse is initially depressed over a launcher icon, the quicklist ignores or doesn't receive events until the mouse is released. Yes, this is a bit of an annoying shortcoming (there is no way to transfer the grab to another widget in nux). I think the way you will need to do it is to XUngrabPointer (grep other bits of the code on how to do this - I think the menus do it) and then then open the menu and make sure it is grabbed currently. Cheers, Sam I guess that I am halfway to a functioning solution: The right mouse doesn't initiate launcher or icon drags, but I can't yet open the quicklist and make a selection in one click. Josh On Sun, Jan 2, 2011 at 8:12 PM, Sam Spilsbury smspil...@gmail.com wrote: On Wed, Dec 29, 2010 at 12:27 PM, Josh Headapohl joshh...@gmail.com wrote: Hello, I'm working on bug 688830 in Unity, which is about letting the user select a quicklist item with just one right click. Currently, you have to let go of the mouse button first or you will just start dragging the launcher icon. This behavior is annoying and the bug is tagged as bite-size so I decided to try to help fix it. Dieder Roche commented it could be bitesize with good mentorship, so I hope I can get a little assistance here in figuring out Unity's technical design. Okay, maybe more than the design. :) There's a lot to take in. I see that when there is an OnMouseDown signal emitted, a Launcher instance will handle it, and I can see where later in the chain of method calls, the quicklist menu item is created and shown in LauncherIcon::RecvMouseDown. What I haven't found yet is what sends the OnMouseDown signal in the first place. For example, in Launcher.cpp line 186, OnMouseDown.connect (sigc::mem_fun (this, Launcher::RecvMouseDown)); What is OnMouseDown and where is it instantiated? Does it happen outside of Unity or am I just overlooking the place where it is created? I think if I could see a higher level source of input events (or do I mean lower?) , if would be easier to see what to do with them further down the line. The launcher class has a fairly long inheritance tree: InputArea - View - Launcher. InputArea is found in nux/Nux/InputArea.h/cpp . It handles raw events (either from X11 or elsewhere) and makes the OnMouseDown etc signals actually emit () once appropriate events are recieved. I have not looked at this particular code in detail, but I would assume that whatever LauncherIcon::OnMouseDown is connected to handles the quicklist creation, button clicks and dragging - although the code that does the dragging isn't checking which button is actually pressed. Regards, Sam Also, if it sounds like I'm approaching the whole problem the wrong way, feel free to point me in a new direction. Thanks, Josh https://bugs.launchpad.net/unity/+bug/688830 ___ Mailing list: https://launchpad.net/~ayatana-dev Post to : ayatana-dev@lists.launchpad.net Unsubscribe
Re: [Ayatana] Graceful degradation of Unity
On Tue, Jan 4, 2011 at 7:52 AM, Mark Shuttleworth m...@ubuntu.com wrote: On 13/12/10 17:17, Spike Burch wrote: What I would do, although this is duplicating effort in the long run, is write a 2d version of unity using EFL, just like they did with the old netbook interface That's what I would do too :-) For 11.04, the focus is on getting Unity-with-GL as good as we can. However, in time for the LTS, we will want a 2D experience which shares enough of the interactions that it doesn't require a second set of documentation. I doubt we'd be able to shove EFL into compiz (Carsten if you are reading this, please prove me wrong), but compiz has had a 2D fallback mode for a while now, and while it essentially turns it into an extremely dumb window manager, it has the capacity to be improved. I'm almost wondering whether setting the baseline on XRender and leaving out any kind of non-compositing is worth pursuing - we can achieve similar views with XRender compositing, although it won't be as fast. As Ryan Prior pointed out, Unity is unproven. We're confident in it - enough to commit to it for 11.04, and the design has been flattered with imitation elsewhere, so that's reassuring too :-). But having the existing Gnome 2 style panel-based fallback is fine in 11.04 because it provides a familiar environment for those who want it, and is stable and well trusted. Mark ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] The Unity launcher and minimized windows
On Fri, Dec 31, 2010 at 12:19 AM, Conscious User consciousu...@aol.com wrote: Hi, Currently the Unity launcher in Natty does not offer any way to restore minimized windows if another window from the same application is opened (the scale plugin is invoked instead, considering only non-minimized windows). I believe the intended behavior for now is to do what was happening last version and to show minimized windows on the spread initiate. The reason why this is taking so long is because I have long held a policy of *not* supporting this behavior since it is full of hacks and breaks many applications which are stupid about the way that they treat minimization. It's in 0.9.2 as a workaround because that's the way it should be IMO. I suppose this is because it's just an alpha, but what is the intended behavior in the final version? Making the scale plugin include minimized windows the same way it includes non-minimized windows, I think it's a bad idea. Minimized windows are in a different state and that should be visually shown. I'm attaching an ugly, made-in-five-seconds mockup with a suggestion: when an icon is clicked in the launcher and some windows of the app are minimized and some are not, the launcher shows the minimized ones as icons below. That way the user knows which windows will be restored and which ones will be just focused when selected. Sounds cool. Unfortunately you didn't attach anything :) It also gives less trouble to compiz by not asking it to generate previews for minimized windows. Too late ;-) ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Put a resize widget in the title bar
On Sat, Dec 25, 2010 at 4:43 AM, frederik.nn...@gmail.com frederik.nn...@gmail.com wrote: Hi Remco, On Thu, Oct 14, 2010 at 13:50, Remco remc...@gmail.com wrote: On Thu, Oct 14, 2010 at 07:16, cmaglothin cmaglot...@gmail.com wrote: I agree. The only reason I ever boot into Windows is that I have to annotate movies for a class, and Snap makes it very easy to do with just two clicks. On Wed, Oct 13, 2010 at 10:34 PM, David Hamm davidth...@gmail.com wrote: in fact i'd say it almost a upgrade deciding factor for vista to 7 You'll like Compiz Grid. I think Frederik's idea is simply a mouse interface to Compiz Grid. yeah, essentially, i would love to see stuff snapping to an invisible grid. This could then be disabled by holding a modifier key such as [ALT]. By default, snap to grid should be enabled for: * moving windows * resizing windows * scaling windows i also suggest strongly to consider window controls as nothing else than what the name suggests: controls for the window at hand. often, we are confronted with the question whether or not closing a window will quit the app contained in it. This is poor design, i mean, window controls are not well designed, if they affect the service instead of only the window. Now about Compiz Grid.. it's remarkable, the windows7 thingy is fully implemented and of course completely configurable to the corner and pixel ;) i jast had an easy time splitting my screen in two halves.. took me 2 click-drag-releases. Thanks to whoever did that in Compiz! It was scott :) He's a dude. Apologies to hijack this thread - I have already got a sample implementation of implementing a resize grip area set by the theme which is larger than the borders and it vastly resolves the precision problem. It requires a patched metacity though ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
[Ayatana] Always include delete button when accessing external storage on nautilus
Hi everyone Just thought of an annoying quirk that could either be papercutted or considered by design - the default nautilus behavior is to always move stuff to a trash folder and not actually delete it unless you empty the trash. However for external volumes like USB sticks and memory cards (and even external hard drives) this does not make sense, since usually the reason for deleting files is because you have backed up the temporary storage (photos, videos, files, etc) and now you need to delete the redundant copy to make more space on the volume. In this case there should always be a delete option in nautilus to delete the files right away. In my opinion the current behavior doesn't make all that much sense to me - the expectation is that the user is to empty the trash to permanently delete stored files, but a persistent trash doesn't make sense with the paradigm of removable storage. At least my expectation always seems to be that each device has it's own trash and must be emptied separately. It would also seem like an unintended consequence that if I emptied the persistent trash on my machine it would also empty the trash on each device - there is no granularity or predictability of what is going to happen. Cheers, Sam -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
[Ayatana] Allowing windows to move past launchers
Hi, I was doing some work on the snap windows plugin for compiz and I was wondering if it is the correct behaviour design wise to allow windows to move underneath the launcher and the panel. Currently we have it so that windows snap to the launcher but the user can move the window past the launcher if they move hard enough but I was wondering if we should even allow windows to move past these panels in the first place. Let me know what you all think. Cheers -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Allowing windows to move past launchers
On Fri, Dec 10, 2010 at 1:33 AM, Mark Shuttleworth m...@ubuntu.com wrote: On 09/12/10 10:59, Didier Roche wrote: Le jeudi 09 décembre 2010 à 18:55 +0800, Sam Spilsbury a écrit : Hi, I was doing some work on the snap windows plugin for compiz and I was wondering if it is the correct behaviour design wise to allow windows to move underneath the launcher and the panel. Currently we have it so that windows snap to the launcher but the user can move the window past the launcher if they move hard enough but I was wondering if we should even allow windows to move past these panels in the first place. Let me know what you all think. We should just perhaps agree on the snap value? I mean, we want to avoid false positive on intellihide but still enabling people to have intellihide :) In the intellihide, moving the window against the launcher should kick the launcher out immediately, as it currently does. I think Sam's referring more to the case where the launcher is locked in place, not intellihide. I was thinking something like this (warning: coder's POV, it gets a bit technical). Bit of lingo here since I tend to use it regularly: - strut: A property called _NET_WM_STRUT_PARTIAL that docks, launchers, etc place on windows to reserve an area of the screen. Windows don't get placed there and they cannot maximize over it. - placement: where the window is positioned on open. My idea was this: 1) On the intellihide case: - We don't set the strut property, which means that windows can implicitly get placed underneath the launcher (this can be overridden in the unityshell plugin) - On maximisation the launcher is going to go away anyway, since the window will be covering it - When moving a window near the launcher, if it goes close then the launcher will go away (intellihide) - When resizing a window, if the resize border touches the launcher, it goes away, easy 2) On the fixed launcher case: - We set the strut property, so no implicit incorrect placement - On maximization the window does not cover the launcher - Windows cannot be resized underneath the launcher - Windows cannot be moved underneath the launcher. The reason for the fourth one is because we have the window buttons on the left - we do not want to have to obscure them in the case that we move a window. Mark ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Allowing windows to move past launchers
On Fri, Dec 10, 2010 at 2:14 AM, Mark Shuttleworth m...@ubuntu.com wrote: On 09/12/10 17:43, Sam Spilsbury wrote: My idea was this: 1) On the intellihide case: [...] - When resizing a window, if the resize border touches the launcher, it goes away, easy I'd like to see a proximity push in this case. When the window is brought close to the launcher, we start to push the launcher away. Say, when the edge of the window is 10px from the launcher, we start to move the launcher 1px for each 2px it approaches. When the window gets to the point where it would have touched the launcher, the launcher goes away. This is easy to implement in compiz. I think this would feel a little more organic and real than the current insta-trigger. The px values might best be shared with the notify-osd proximity-effect fade boundary too. 2) On the fixed launcher case: - We set the strut property, so no implicit incorrect placement - On maximization the window does not cover the launcher - Windows cannot be resized underneath the launcher - Windows cannot be moved underneath the launcher. The reason for the fourth one is because we have the window buttons on the left - we do not want to have to obscure them in the case that we move a window. Let's do some testing with a less rigid interpretation - allow the window to be resized or moved so its left edge is under the launcher, but make sure it encounters some resistance when it touches, before pushing through under the launcher. Right. I'll look into implementing edge resistance for resize as well in the snap plugin Mark -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Compiz Search Filter for default
On Wed, Aug 4, 2010 at 10:05 PM, Frederik Nnaji frederik.nn...@gmail.com wrote: Hello dear CompizConfig Developers in this list, if there are any.. are there any? A great thank you for how you did the search filter in CompizConfig Settings Manager, that's the kind of filter that makes sense. The gtkfilechooser module was reinvented in Sezen, still its legacy or better to say aging version deserves some love i say! let'S give the quick search filter another look real quick here: in CompizConfig Settings Manager, our main control interface to the window manager software control, the search filter for text elements is openly visible, affording itself to the user: There are too many controls to fit into one page, so a UI object should provide for a way to instantly focus initially invisible objects. A scrollbar doesn't give instant access to an object, as a visually optimized list or gallery would for example do. ¹ check the attached screener for visual reference! ² how would this look on all scrollable pages in 10.10 (pages or dialogs, unable to display all of their content at once automagically) ? greetings.. Yes, developers do lurk on this list, but if your query is directed towards CCSM itself you should use the appropriate commun...@lists.compiz-fusion.org. As for your question, I don't really understand what you mean - are you saying that for places where there are too many options only the most important ones should be available first? In that case, I would say application designers should really focus on providing only important configuration modules. Compiz is a special case since it was designed with full configuration in mind. CCSM does not ship with Ubuntu linux. You should instead use Simple CCSM if you wish to make basic configurations to Compiz. Cheers, ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Compiz Search Filter for default
The whole point of CCSM is to display all available internal variables. I don't see how trying to smart filter them out fits in with the purpose of CCSM. The developers have already picked a set of options which control the majority of the program, in an application called Simple CCSM. I suggest you try that? On Wed, Aug 4, 2010 at 11:15 PM, Frederik Nnaji frederik.nn...@gmail.com wrote: FWIW, here's a little explanation about what motivated me to write this: i believe that the concept of abstract navigation is becoming mandatory. Any human-friendly man machine interface deserves to move beyond spacial axis vs time for navigation.. I think we can do more in terms of navigation than pan, scroll and turn page., i.e. physical movement. The human mind is able to understand concepts far beyond physical movement along a spacial axis. We dance and swim in water, soil and air simultaneously with our eyes closed.. How could spacial navigation ever be more important to such a being, than conceptual navigation? To be honest, i believe that the man machine interface was never more retarded than with the increasing age of the desktop metaphor. Files and folders are the models an Operating System uses to associate content objects with other content objects. The user should not be bothered with such details anymore! We all want software technology interfaces to be helpful in that they make life simpler with all that they can help us do.. I think we can consider software appliances to be our artificially augmented sense of coordination; imagine searching the www with only the usage of scrollbars and arrow keys: unuseful. Sense of coordination is a scaling factor for mental capacity. meaning for the ability to identify a known concept when it appears. The system has the ability to re-cognize abstract concepts, as soon as it is able to coordinate virtual relationships between their elements. To put it in other words: Spacial navigation interfaces are useless on invisible objects. I'd go even further and say: never display unmanaged content. Don't display stuff if it doesn't fit into the immediate purpose of something i'm currently doing. when i'm looking for a file for example, i am not interested in seeing any other files, so searching for one particular document is more important than displaying all of them simultaneously, spacially organized. We need to give navigating a serious lift. To achive this, it would help to put logical navigation into the foreground wherever spacial navigation would obviously be more tedious to perform, i.e. invisible content. The reason is simple, or let me say simplicity itself! The sea of invisible (virtual) objects in the world of software technology is so overwhelming, that simple ways of navigating it are yet to be produced.. On Wed, Aug 4, 2010 at 16:05, Frederik Nnaji frederik.nn...@gmail.com wrote: Hello dear CompizConfig Developers in this list, if there are any.. are there any? A great thank you for how you did the search filter in CompizConfig Settings Manager, that's the kind of filter that makes sense. The gtkfilechooser module was reinvented in Sezen, still its legacy or better to say aging version deserves some love i say! let'S give the quick search filter another look real quick here: in CompizConfig Settings Manager, our main control interface to the window manager software control, the search filter for text elements is openly visible, affording itself to the user: There are too many controls to fit into one page, so a UI object should provide for a way to instantly focus initially invisible objects. A scrollbar doesn't give instant access to an object, as a visually optimized list or gallery would for example do. ¹ check the attached screener for visual reference! ² how would this look on all scrollable pages in 10.10 (pages or dialogs, unable to display all of their content at once automagically) ? greetings.. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] CSD and the pressure to innovate
On Wed, Jul 7, 2010 at 5:42 PM, Apoorva Sharma appi2...@gmail.com wrote: On Jul 7, 2010, at 6:10 PM, Sam Spilsbury smspil...@gmail.com wrote: Why exactly do we want the WM to be handling tabs here? Trying to do tabbed applications within the window manager for the sake of having tabs is a huge waste of memory, especially when the application itself can already do tabs. Standardizing a tabbing system would save memory, since individual apps don't have to manage them, and so unnecessary code could be removed. No, the removal of code to do internal tabbing has nothing to do with memory wastage. First of all, you are still going to be linking against the GTK or QT libs for any application and have fun getting any of them to remove their tabbing widgets. So that code isn't going to be saved. Second of all, window managers know nothing about documents, they only know about X11 windows (which are just huge images as far as they are concerned). If you want to standardize tabbing into the window manager that is fine, but keep in mind that the window manager has to keep the pixmaps of those windows around at all times in order to tab between them. This in itself is huge memory wastage. If you keep things within the toolkit as they are already done so now, then the toolkit knows about documents and knows what bits of memory it does and doesn't need when switching between documents. In addition, you have /one/ pixmap rather multiple pixmaps. It also does not make sense from a design perspective. the whole point of tabbed windows (as it is implemented in both Compiz and KWin) is to allow multiple /applications/ to be shoved into one window, applications which the user delegates themselves as related. Confusing documents and windows here doesn't help at all. I agree. However, what do tabs in firfox, chrome, and nautilus do? They allow one to combine multiple windows into one. Thus, the current tabbing system used by compiz should be scrapped (at least to me, it provides no benefits by combining two applications into one window) and there should be a system where all windows are tabbed into one like Chrome does it. It saves space, allows apps to use less code, and provides a way to unify tab behavior across applications. They don't combine multiple windows into one. They combine multiple /documents/ into one. Document != Window. A document just so happens to be the thing you are doing operations on. A window includes that document, but /also/ includes tools to operate on that document, such as cut, copy, paste, toolbars etc. Also if you just want to tab items in a singular application, then why not use the tabs implementation we already have? Toolkits have been able to do this for years, and because applications already use toolkits, the implementation is already consistant! There, no more ugly window manager hacks required. Kind Regards, Sam I hope that this alternate description helps. -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Windicators
On Wed, Jun 23, 2010 at 8:59 PM, Mark Shuttleworth m...@ubuntu.com wrote: On 18/06/10 19:42, Sam Spilsbury wrote: Do you need to interact with them during alt-tab? Remember that your screen is grabbed and you are busy finding windows, not tweaking them. I think, if we're going to expose them, we should enable them to be interactive in order to keep them faithful to the original and consistent. In that case, I'd say scale them down accordingly. Not only will this fit in better more visually, but it also makes a heck of a lot of sense when we get input redirection and can interact with those tiny widgets anyways* They'd be tiny, and not very easy to interact with scaled down. It's a neat idea, but I think violating the scaling is actually useful in this case. Mark I have been running my own builds of X11 with input redirection for about a year now, since your display would become largely resolution independent anyways and you can just zoom in to get more precision on those little widgets. Kind Regards, Sam -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Windicators
On 6/18/10, Mark Shuttleworth m...@ubuntu.com wrote: On 18/06/10 15:00, Sam Spilsbury wrote: Yes, perhaps show them at 1:1 scale as emblems on the window previews, whatever the underlying window scale is for the reveal / alt-tab. Mark I would imagine with 24x24 icons you're going to have enough room for about 4 of them on each window thumbnail before they start running off and things get ugly fast. Even with 18x18, I'd say 5 is pushing it. I guess you could increase the size of the window thumbnail, but I don't see how that would fix much. What happens if applications have more than 4 or 5 indicators? We'll have to think about that :-) Suggestions? Show the ones that most recently changed status? Do you need to interact with them during alt-tab? Remember that your screen is grabbed and you are busy finding windows, not tweaking them. In that case, I'd say scale them down accordingly. Not only will this fit in better more visually, but it also makes a heck of a lot of sense when we get input redirection and can interact with those tiny widgets anyways* *I'm going to at least try to push for this in the next few weeks in upstream X11. -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] [Fwd: Re: Fwd: Open Letter: The issues with client-side-window-decorations]
On Thu, Jun 10, 2010 at 2:48 AM, Cody Russell brats...@gnome.org wrote: From: Martin Gräßlin k...@martin-graesslin.com It would be unacceptable that windows cannot be closed if they hung. Hi Martin, Sorry I've been absent from this discussion, I haven't really felt I had much to say yet. And I generally avoid Ayatana list because I have the same problem you have with it.. all the email goes to my @canonical.com but whatever I write from that address gets blocked, while mail from my @gnome.org goes through for some reason. Anyway, I just wanted to comment on this statement and point out that this is not a hugely difficult problem to solve with some cooperation from a WM. I would assume a WM can monitor _NET_WM_PING and either popup a dialog, or we could create a hint to expose a region of the close button to the WM for this purpose. So one reason I have not been commenting on this discussion is that quite frankly, I agree with you that right now they may not be ready to land in a distribution due to many of the problems you have cited. It seems sort of clear to me that there needs to be more development time in order for CSD to catch up in certain respects. However, this in itself is not a reason to abandon the development effort altogether. From what I can tell, window manager decorators need to jump through an extraordinary number of hoops in order to make a window decoration and the application appear to be one. KWin seems to do this really well, and I think we're all really impressed with it. But at the same time, why should we not explore the opposite approach as well? Rather than having two processes trying to draw what is essentially the same application and do a lot of work to make them look the same, why not try drawing them from the same process and do less work to get the functionality back (e.g., the close button hint I described above)? This strikes me as being a lot less work than trying to do in our WM what you've done in KWin. If you're talking about reparenting, then pretty much every window manager does this. Including metacity and mutter. Compiz sort of does in upcoming versions, although for a while now it has used a hack where decorations are drawn as an auxiliary texture around windows. In every usecase where this applies (remember that there is always the fallback i can't do this ewmh hint that wouldn't be read), I'm sure that for every window manager that draws a decoration window, it is not incredibly difficult to draw a few more pixels. Unlike adding a bunch of workarounds to cope with CSD. I disagree that our approach is fundamentally flawed. But I admit that I do agree we perhaps should not be pushing it into our distro yet, and we should be working with you guys on wm-spec-list more to discuss issues like the hints I described above before we try to really release it. This is my fault, not some Canonical conspiracy to try to fuck you guys over or anything. ;) I'm dealing with other projects, and due to the relatively short development cycle for Ubuntu it sometimes makes it difficult for me to plan and execute proper coordination with upstreams, especially ones that I'm not very familiar with (such as wm-spec-list). I'll take full responsibility for that, so please don't hold it against Ubuntu or Canonical. Hold it against me if you want to. ;) As a sidenote, even though I stand on the csd's are bad side of this flamewa^Wdiscussion, I don't want to give the impression that I'm in any way hostile towards canonical for their design decisions, and even if after realizing that canonical is essentially ignoring the developers of the very projects by which they depend, I'll be happy to accept patches upstream to make CSD work *somewhat* well. However, I won't accept patches that require that people use CSD, and I don't have the time to write the CSD code myself, since I am incredibly busy with my university degree. Kind Regards, Sam. / Cody -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Putting some brakes on the enthusiasm
On Thu, Jun 10, 2010 at 5:38 AM, Mark Shuttleworth m...@ubuntu.com wrote: On 09/06/10 22:31, Martin Owens wrote: Desktop experience and design studies and such I'd love to see more discussion here in this list. Yes, I think we should keep implementation issues away from this list. The CSD discussion, for example, has little to do with the user experience we wish to create. That is a bad idea. You cannot just say we're going to use [insert technology X], but that does not matter since what we care about is design without ignoring the many upstreams who will ultimately be incredibly upset by that technical change for the sake of design. I really don't want to say it, but I seriously considered ceasing all development of a core ubuntu technology (compiz) today after what happened yesterday on the mailing lists. I don't ever want to work in a situation where other people are making my life harder. Canonical and ubuntu need to realize that the very upstreams they depend on do work out of the generosity of their heart and have a sound knowledge of how things work. Using a large desktop share and the sake of design to ignore technical issues is a surefire way to create walls between you and your upstreams. Kind Regards, Sam ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Fwd: Open Letter: The issues with client-side-window-decorations
On Wed, Jun 9, 2010 at 12:13 PM, Ted Gould t...@ubuntu.com wrote: On Mon, 2010-06-07 at 15:01 -0400, Scott Kitterman wrote: Without CSD there is nothing to fix. I'd prefer not breaking things in the first place and that's one small point. I still don't know what you want out of CSD the merits all the work to patch apps back into the consistency we already have. I think that for sure we're making some problems that have already been fixed, but I think that is also descriptive of the current situation that we have. It's a local maxima. I think every direction is down hill, but there's another mountain for us to climb that is higher than where we are now. On Tue, 2010-06-08 at 18:41 +0200, Martin Gräßlin wrote: As mentioned in my open letter: I want to help you. I am willing to spend my time and expertise on this issue to ensure that we don't end with an utterly broken CSD library in GTK 3. Cool, that is great! But, I'm worried that we're approaching this from different assumptions. My reaction there is let's figure out how to make CSD work while yours seems to be let's figure out how to get window decorations to work. So, I guess my question is: If we assume that the window manager isn't going to draw decorations, how can we make that works as good as possible with KWin? On Wed, 2010-06-09 at 10:18 +0800, Sam Spilsbury wrote: As far as I know, with martin's NETWM idea to have the decorator paint the behind of the window, this basically means that the window can be reparented at 0x0 in the decoration, rather than the offset of the decoration. This means that they are free to draw whatever they want on top of the decoration (tabs, particles, etc) and have it all blend. Developers would be nice though *cough*. First, Sam thanks for explaining this. I was confused on the NETWM idea. And I guess that I still am a little. If the application can draw over the decorations, what gain in consistency is there by not having the application theme draw the decorations themselves? It seems like having two theme engines just for fun at that point. It allows for consistency of decorations while allowing consistency between the application and the decoration. The whole idea is to have a NETWM (or EWMH as it goes by) spec which the application sets when only painting it's decoration on a window with an alpha channel (and then not painting the usual grey or cream colored background). With this setup, you'll get a consistent background look to all the applications and a consistent background look between the decoration and the window, whilst retaining the benefits of having the window manager reparent the window into a decoration and have a consistent control for all the windows. Compare Martin's screenshot of rekonq with such a setup and, for example, windows explorer on windows aero. Yes, I'm aware that you can do all of this with decorations on the client side. However, doing such is a bit of a cheap way of doing things, since you drop reparenting into window manager controls. --Ted -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Criticism of Client Side Window Decorations
there? I don't understand this design inconsistency where we are putting some things global and some things local. Then again, putting windicators global is probably just going to result in each indicator being duplicated on the panel, so you'll have two sound menus (local and global). Or maybe you could just drop the whole windicators thing and put all your indicators in indicator-applet with application specific menus tied into the global ones. Thanks, Dylan ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Criticism of Client Side Window Decorations
On Sun, May 16, 2010 at 10:46 AM, Frederik Nnaji frederik.nn...@gmail.com wrote: hi sam On Sun, May 16, 2010 at 03:41, Sam Spilsbury smspil...@gmail.com wrote: So the window controls are essentially invisible unless you play a hide an seek game with your mouse? I don't understand why you'd want this - and it requires some form of meaningful acceleration within apps, something that I don't think everyone has. AIUI it has something to do with mouse pointer position relative to the window border.. I don't understand where acceleration would fit into this context.. If you want to make the fading smooth, then you will most likely need some form of graphical accelleration, whether that be EXA, Glitz or G3D. There is no way to guaruntee that everyone has this. You have a point with your cat and mouse game though.. You cannot do this with client side decorations. why not? because of the imprecision of the absolute position information? that's a WM bug, has nothing to do with CSD. Some window managers have to fake out position information to make this kind of thing work. Usually this is because they are reparenting the window (metacity, kwin) or they are a compositing window manager with input redirection and have to place the window offscreen to redirect input to it on-screen (Metisse, future versions of compiz). In any case, there are methods of a client determining it's position on the root window, however this is inaccurate at best and something the client shouldn't need to be concerned with. If you wanted to do separated titlebar handles, there is a lot of work that needs to go into that, namely the client drawing titlebars in a separate window and either reparenting that window into itself or drawing it separately. Which kind of begs the question - why not just let the window manager do that because it already does. If you let the window manager do this, then you can guaruntee that the titlebar will be consistent with the rules the window manager has defined and client won't all just do their own thing when their titlebar is off-screen. The window manager absolutely depends on the client to not be stupid and to obey rules Doesn't this mean that we can entrust the client with more then? You are arguing against your own position here. When you have client side decorations, you give more chances for the client to be stupid and introduce it's own window management paradigms, drawing the buttons the window manager does not expect to be drawn, or in extreme cases resizing or moving windows in special ways when they are grabbed by the titlebar. Regards, Sam -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Windicators
On Mon, May 3, 2010 at 10:01 AM, Mark Shuttleworth m...@ubuntu.com wrote: On 03/05/10 13:22, Roth Robert wrote: Another tiny detail I have a problem with... having progress status indicators on the top right side and having the transient status message appear on the bottom left side seems strange... do the status messages have to appear on the bottom left? Until now it was fine because the progress indicator was in the statusbar and the status message also, but these belong together in my opinion. What if they'd appear below the windicators for a short time? That's an interesting idea. One issue might be that the toolbar usually shows right below the window title, and it's harder to imagine the status message over the toolbar than over the content. Going even further with the idea... what if they would be NotifyOSD messages with smaller bubble, font, and positioned below the window border? We *could* do an overlay, yes. Sorry to hijack this discussion on to a slightly more technical issue, but I'm not particularly sure where the whole idea started. While I am in favour of the design aspects of windicators (per-application volume control from the window itself sounds great), I am slightly skeptical as to how this could be implemented in both the compiz, mutter and metacity codebase, considering the fact that currently the window decorations are drawn as a GDK image in metacity and an X Pixmap / GTK image in compiz and the only way of interacting with them is a series of input windows in predefined places. In order for this to work, you would have to either a) Go and extend libwnck to allow placement of random pixmaps and input windows in decorations (something which will not work well) or b) Implement gtk widgets within the decorator (which is something similar to the libdbus notifications that ubuntu is doing right now) If it's the latter that is the case, gtk-window-decorator and metacity will both need some heavy lifting. How do we plan to implement this and will any work be done upstream. Kind Regards, Sam Spilsbury (Concerned Upstream) Mark ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
