Re: [Ayatana] Lack of harmony between panel applets
On 28/06/10 03:34, Tyler Brainerd wrote: On Sun, Jun 27, 2010 at 7:32 PM, Allan Caeg allanc...@gmail.com mailto:allanc...@gmail.com wrote: Will indicator-network feel integrated with Indicator Applet and Indicator Session? If indicator-network is right beside Indicator Applet, will it follow that mouse hover menu activation will jump between the two panel applets? As for the clock applet, does anyone here know if it will work the same way as indicator-network? That is the design intent, yes. If you are running only Ayatana indicators, then yes you will be able to have a menu only experience end-to-end. For 10.10 that will mean using connection manager, which will still have rough edges, and the clock indicator, which is relatively simplistic. But it will still feel tighter and more unified than a hodge-podge of panel applets, so that's how I'll be using it :-) Mark signature.asc Description: OpenPGP digital signature ___ 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] Places People
On Mon, 2010-06-28 at 02:25 +0200, Frederik Nnaji wrote: 2. In which of the above categories would you prefer to see Contacts.. Personal or rather Network? or perhaps a new People category? Network is for your local (computer) network and thus no place for Contacts/People. Not all contacts/people a user wants or has to manage are what they would call personal. People and Contacts are not quite the same. The first implies or encourages bundling of as much information as you you can get, while the later puts an emphasis on addresses and communication channels. 3. What do you know about the concept of Places and how happy are you with the current implementation of it? I think the Desktop folder has great potential to confuse users with its special dual presence. The whole dual approach of having a single-rooted filesystem and Places on top of it presents a scary conceptual depth. David suggested we discuss specifically the integration of metacontacts in Unity's launcher, so please ppl, let it happen ;) _meta_contacts? I'd prefer to call it people/profiles if it's about bundling addresses belonging to a single person. Hmm, there's also the question of how to model organizations, where you might have addresses that do not map to persons. Call it Groups if it's about collecting addresses in a mailing list or newsletter style. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ 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] Lack of harmony between panel applets
On Mon, 2010-06-28 at 07:45 +0100, Mark Shuttleworth wrote: If you are running only Ayatana indicators, then yes you will be able to have a menu only experience end-to-end. For 10.10 that will mean using connection manager, which will still have rough edges, and the clock indicator, which is relatively simplistic. But it will still feel tighter and more unified than a hodge-podge of panel applets, so that's how I'll be using it :-) So long as it has 24 hour clock, seconds and an ability to display a basically a custom datetime format of my choosing through some non-ui configuration. I really like iso date/time. Although I hear it'll unravel all the functionality for the evolution calendar and task list as well as the handy locations and ability to change locations from that menu. Is that true? Martin, ___ 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] Lack of harmony between panel applets
On 28/06/10 08:33, Martin Owens wrote: Although I hear it'll unravel all the functionality for the evolution calendar and task list as well as the handy locations and ability to change locations from that menu. In due course, similar capabilities will be added. But for the moment it's minimalist. signature.asc Description: OpenPGP digital signature ___ 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] Lack of harmony between panel applets
In due course, similar capabilities will be added. But for the moment it's minimalist. Here's me hoping that those similar capabilities will be implemented in a neat d-bus service way which follows an app-independent protocol, thus closing one of the most common complaints against the current clock, which is being too tied to Evolution. ___ 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] Places People
On Mon, Jun 28, 2010 at 9:05 AM, Thorsten Wilms t...@freenet.de wrote: On Mon, 2010-06-28 at 02:25 +0200, Frederik Nnaji wrote: 2. In which of the above categories would you prefer to see Contacts.. Personal or rather Network? or perhaps a new People category? Network is for your local (computer) network and thus no place for Contacts/People. Not all contacts/people a user wants or has to manage are what they would call personal. People and Contacts are not quite the same. The first implies or encourages bundling of as much information as you you can get, while the later puts an emphasis on addresses and communication channels. Helpful further reading specifically on that: http://www.boxesandarrows.com/view/designing-for-social (Designing for Social Interaction – Strong, Weak, and Temporary Ties) 3. What do you know about the concept of Places and how happy are you with the current implementation of it? I think the Desktop folder has great potential to confuse users with its special dual presence. The whole dual approach of having a single-rooted filesystem and Places on top of it presents a scary conceptual depth. This reminds me that I always wonder why not just the desktop space is used for file management. Basically, marry the file manager (or better: file browser) with the desktop background. Integrate some of the file managers’ back and forward or breadcrumb controls. Ubuntu and Mac OS already shows mounted drives but that’s just a half-assed implementation. I have to think this through more. Sorry for derailing the thread a bit. ;) ___ 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] Design discussion proposals for Christmas
On 31/12/09 17:20, Conscious User wrote: But *can* the current specification fix this for closed-source apps like Skype? The reason I ask (and forgive me if I'm wrong) is that Application Indicators seem to solve the problem of notification area consistency but not the problem of notification area abuse. Even if Skype were to follow the libappindicator API to the letter, it could still *force* an indicator icon to appear, and this is something that displeases a lot of users. In the case of Skype, there is now a library that we can use to integrate it into the desktop more effectively. Mark signature.asc Description: OpenPGP digital signature ___ 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] How Mozilla does community-driven open source design
See http://tinyurl.com/2ebzvww for an article on Mozilla's community-driven design efforts. An interesting caveat from the article: Some commentators doubt that an open source approach can be fruitfully applied to design. There are plenty of good ideas, but they don't work well together with the real world, says Jakob Nielsen, principal at the Nielsen Norman Group in Fremont, Calif. Open source encourages the addition of new solutions and ideas. In design, says Nielsen, the brilliant idea can be the one unifying idea that can take away 10 other ideas. Can anyone cite an example of a unifying idea that can take away 10 other ideas from the Ayatana list, or are we generating plenty of good ideas [that] don't work well together? What can we learn from Mozilla's efforts in this arena? Mozilla's communiy-design epicenter: http://mozillalabs.com/conceptseries/ David ___ 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] Lack of harmony between panel applets
On 28/06/10 08:53, Conscious User wrote: In due course, similar capabilities will be added. But for the moment it's minimalist. Here's me hoping that those similar capabilities will be implemented in a neat d-bus service way which follows an app-independent protocol, thus closing one of the most common complaints against the current clock, which is being too tied to Evolution. Agreed! signature.asc Description: OpenPGP digital signature ___ 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] Fullscreen Mode for all applications
2010/6/28 Tyler Brainerd tylerbrain...@gmail.com Yes for consistency, but I'm not sure how needed this is. I for one would never have a need to have transmission or nautilus fullscreen, or the contact list. These would all be better off with a fixed width and getting maximized vertically. For most apps, you wouldn't press F11 then. :) Perhaps applications could set hints that they want to do something else, for those that are really unsuitable for real fullscreen, but may have an alternative that makes sense, like the contact list? / K ___ 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] How Mozilla does community-driven open source design
On Mon, 2010-06-28 at 11:13 +0100, David Siegel wrote: Can anyone cite an example of a unifying idea that can take away 10 other ideas from the Ayatana list, or are we generating plenty of good ideas [that] don't work well together? I understand that quote to likely refer to a situation, where you see ideas for solving several problems that are actually symptoms of a deeper issue. So one good idea leading to a solution of the deeper issue renders them obsolete. That's why it's a good idea to start with (in no particular order): * Are you targeting the right problem? * Can the problem be avoided / worked-around? * Is it perhaps a symptom of an underlying issue? Hmm, I have a hard time thinking of examples. I blame it on the hot weather here. All my ideas there revolve around being lazy possible ... I mean: as lazy as possible :} If you are worried about a hodge-podge of ideas not working well together, documented goals and assumptions should help. What can we learn from Mozilla's efforts in this arena? Doing design challenges could be worth it. http://design-challenge.mozillalabs.com/ -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ 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] Fullscreen Mode for all applications
FYI, If I remember correctly, GNOME's keybinding app lets you choose a keyboard combination to switch any window to fullscreen (even if it doesn't nativelly support it). -- Siegfried-Angel Gevatter Pujals (RainCT) Free Software Developer 363DEAE3 ___ 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] File transfer dialog behaviour
On Mon, Jun 28, 2010 at 11:55, Matthew Paul Thomas m...@canonical.comwrote: Sorry, I still have no idea how that relates to progress windows. The progress window when unmounting a device, for example, correctly has no close button. It doesn't need CSD to achieve that. you're right, CSD is not needed for progress, but it catalizes it. ___ 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] Broadcasting from Me Menu: thoughts after some time using it
On Mon, Jun 28, 2010 at 12:08, Mark Shuttleworth m...@ubuntu.com wrote: On 01/06/10 15:36, Conscious User wrote: After some time actually using the Me Menu in Lucid, though, one thing is bothering me with respect to the specification itself: the lack of any kind of feedback in case the broadcasting went well. The specification states that notification bubble should be only sent if some error has occurred. I thought it would be just a matter of getting used to it, but after a long time that didn't happen: I just *had* to open Gwibber after posting something in order to make sure it was there and have peace of mind. Can someone shed a light on the *exact* reasoning behind the *total* absence of feedback? I'd suggest sending a notification bubble if the broadcasting was successful as well. That said, however, he Me Menu is already very convenient now, thanks to polishing such as automatically focusing the text bar, allowing me to just click on the indicator and start typing. With a little more polish, it can be quite awesome in this age of constant microblogging. We can (and should) provide a spinny in the indicator icon itself during the transmit phase, and use a green or red flash (like the one you get during ajaxy updates in Launchpad) to indicate success or failure. That would be great. Still i miss the custom status for IM alongside the MeMenu's presence settings.. where is it? Available, Away, Busy, even Invisible are there, but no custom text status.. i like the idea of easy access to microblogging whether i have my clothes on when i come out of the shower or not, but i'd prefer to put the blogging use case where blogging is handled, and not so ambiguously close to IM presence settings. ___ 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] Fullscreen Mode for all applications
Hi Siegfried, On Mon, Jun 28, 2010 at 13:39, Siegfried Gevatter rai...@ubuntu.com wrote: FYI, If I remember correctly, GNOME's keybinding app lets you choose a keyboard combination to switch any window to fullscreen (even if it doesn't nativelly support it). yeah, Compiz can do that to a window. On Mon, Jun 28, 2010 at 04:09, Frederik Nnaji frederik.nn...@gmail.comwrote: Fortunately, Compiz has window rules which can allow for toggling of fullscreen mode for any app. Unfortunately, this feature is buggy, as gnome-panel will sometimes cover a fullscreen app, instead of disappearing behind it or autohiding. i think a fullscreen mode is different from the ordinary window mode. The worst example for how to design a fullscreen mode was what i found in the current Epiphany release. Epiphany rocks, really, i love it, even if it has some rough corners. But i have a mouse way of getting into fullscreen, and NO mouse way of leaving it. That's a problem. What is fullscreen? Fullscreen is a way of using all the screen pixels to focus mainly the content an application is trying to communicate to a user. Every application should decide by itself, what content is relevant while in this special mode of window focus. Some apps might even request FUSA/MeMenu to set itself to busy automatically, which definitely should be optional if implemented as a feature. Back to Epiphany, while in fullscreen mode, it still shows a navigation bar and doesn't autohide the tabs toolbar.. this totally misses the point of fullscreen mode. In fullscreen mode, an app should display content only, perhaps a few controls where appropriate, no redundancy at all concerning window chrome or anything decoration-wise.. or what is the meaning of fullscreen in your opinion? ___ 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] How Mozilla does community-driven open source design
Hi Thorwil, On Mon, Jun 28, 2010 at 13:25, Thorsten Wilms t...@freenet.de wrote: On Mon, 2010-06-28 at 11:13 +0100, David Siegel wrote: Can anyone cite an example of a unifying idea that can take away 10 other ideas from the Ayatana list, or are we generating plenty of good ideas [that] don't work well together? The worst case is that 10 ideas go to waste for one. The best case is that 1 idea unites 10 ideas and gives them true purpose for the first time. In military we learn: ready yourself for the worst case, aim to achieve the best case results. I understand that quote to likely refer to a situation, where you see ideas for solving several problems that are actually symptoms of a deeper issue. So one good idea leading to a solution of the deeper issue renders them obsolete. This is called a higher level solution. That's why it's a good idea to start with (in no particular order): * Are you targeting the right problem? * Can the problem be avoided / worked-around? * Is it perhaps a symptom of an underlying issue? underlying or higher level mean the same thing here, so i agree again ;) Hmm, I have a hard time thinking of examples. I blame it on the hot weather here. All my ideas there revolve around being lazy possible ... I mean: as lazy as possible :} bein lazy is the true secret, my math teacher always told me. We want equations to be simple, as simple as possible, so that there is no redundancy in the formula. A large term containing redundant expressions should be reduced to its formal essence. The best example for this is Google, who learn asymptotic analysis in MIT's algorithms class, then go on to make billions with that knowledge. Theta notation and similar methods all base on being sloppy, lazy and allowing for a greater fault tolerance, in order to see a bigger picture more clearly. remember: to see a bigger picture, you need to lean back and relax your iris :D What can we learn from Mozilla's efforts in this arena? Doing design challenges could be worth it. http://design-challenge.mozillalabs.com/ good idea! ___ 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] Lack of harmony between panel applets
On Mon, Jun 28, 2010 at 12:15, Mark Shuttleworth m...@ubuntu.com wrote: On 28/06/10 08:53, Conscious User wrote: In due course, similar capabilities will be added. But for the moment it's minimalist. Here's me hoping that those similar capabilities will be implemented in a neat d-bus service way which follows an app-independent protocol, thus closing one of the most common complaints against the current clock, which is being too tied to Evolution. Agreed! +1 now that someone said Evolution, let me suggest something to make the indicators more harmonious ;) Messaging Menu and MeMenu are struggling not to duplicate each other's work, both are looking to develop their respective individual identities. I suggest, give them identities: MeMenu stays responsible for Me-related stuff such as account settings that are tied to it, and it should handle instantly relevant stuff such as VoIP phone calls, Instant Chat Messaging and Presence. Messaging Menu does all that has to do with non-instant messaging, such as broadcast, email and News. Especially the broadcast field from the MeMenu rather belongs to the Messaging Menu, if you ask me. This way we would keep a clear line between the two menus, i would intuitively find what i'm looking for, since i know that one topic/category is covered in one menu, another topic/category is covered in the other menu. All i need to remember now is the indicator applet icon that stands for non-instant messaging, and the other one that stands for what would encompass the instant stuff.. ___ 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] Unity Screenshot
Of course that discussion is not off topic! Please, share your thoughts. David On Mon, Jun 28, 2010 at 1:37 PM, Frederik Nnaji frederik.nn...@gmail.comwrote: We all love what's coming, so here a screenshot of how things could look once this train is up and running nicely. Thanks to the entire team @ canonical!!! This is going to be an incredible UI experience ;) i hope this is not off topic.. Is discussion of Unity's current state and possible features based on the current testing experience OT for this ML? ___ Mailing list: https://launchpad.net/~ayatanahttps://launchpad.net/%7Eayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatanahttps://launchpad.net/%7Eayatana 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
[Ayatana] Condensed menuitems
Jorge Castro just pinged me and showed me the following: http://googlesystem.blogspot.com/2010/06/google-chrome-tests-unified-menu.html Kind of interesting, and I thought I'd post it to the list (if it hasn't already been posted) and see what our design-minded community thinks of these types of condensed menuitems. They strike me as potentially interesting since we're always looking for ways to save vertical space on UNE. The obvious issue is that accelerator/shortcut labels are not displayed for these items. Another potential issue is that it could affect the feel of left/right keying between menus. This is not really an issue so much for Chrome since they only have one menu here. / Cody ___ 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] Condensed menuitems
On Mon, Jun 28, 2010 at 11:19 AM, Cody Russell brats...@gnome.org wrote: Jorge Castro just pinged me and showed me the following: http://googlesystem.blogspot.com/2010/06/google-chrome-tests-unified-menu.html Kind of interesting, and I thought I'd post it to the list (if it hasn't already been posted) and see what our design-minded community thinks of these types of condensed menuitems. They strike me as potentially interesting since we're always looking for ways to save vertical space on UNE. The obvious issue is that accelerator/shortcut labels are not displayed for these items. Another potential issue is that it could affect the feel of left/right keying between menus. This is not really an issue so much for Chrome since they only have one menu here. / Cody That unified menu has a “Tools” submenu. As a result, I am not a fan. “Tools” is meaningless, especially given that the menu itself is a picture of a tool. The computer is a tool. Copy Paste are tools. The keyboard is a tool. A boat anchor is a tool. Submenus are evil, too, and that is one thing the Chrome menu often does a great job not having. Every time you add a layer of categorization, you are hiding something and forcing somebody to slow down. If the things in that category have so little to do with each other that “Tools” is the best possible adjective, They Don't Belong In A Category! Having commented grumpily about that new design, Chrome as it is provides a wonderful example of the value of condensed menus. Their two menus on the top right are considerably more meaningful, and better categorized, than the 5ish menus we have in most Gnome apps. In addition, Chrome's menus aren't attached to a 100% wide horizontal bar that takes up the rest of their space, so there is no further incentive to expand them “because there's room, so it may as well be used.” Because the menu works so well, Chrome doesn't need another 100% wide bar with big icons below it. The menu already does the job properly. How did they do it? Simple! They didn't give in to “tradition.” They didn't think “we'd better have a File menu and stick Quit and Options under there because everyone else does.” Instead, they designed the menu layout that makes the most sense for their specific application. They created their own narrow categories that perfectly group the functionality specific to a web browser. Clever, indeed. ___ 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] Condensed menuitems
On Mon, Jun 28, 2010 at 8:19 PM, Cody Russell brats...@gnome.org wrote: Jorge Castro just pinged me and showed me the following: http://googlesystem.blogspot.com/2010/06/google-chrome-tests-unified-menu.html Kind of interesting, and I thought I'd post it to the list (if it hasn't already been posted) and see what our design-minded community thinks of these types of condensed menuitems. They strike me as potentially interesting since we're always looking for ways to save vertical space on UNE. The obvious issue is that accelerator/shortcut labels are not displayed for these items. Obviously, but when you think of it: If you use the menu for copying and pasting, you are clearly _not_ a keyboard shortcut person. And everyone else knows the combinations anyway. Sure, the learning effect is destroyed. But how much is it worth to have a cluttery shortcut hint displayed that you are going to ignore anyway when you can have an awesome bundled function pair? We don’t really need a way to access the menu faster (as in global menu), we need a way to access the _items_ faster. Chromium and Mac OS help search serve as great examples. ___ 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] Broadcasting from Me Menu: thoughts after some time using it
Hi. On Mon, Jun 28, 2010 at 12:08, Mark Shuttleworth m...@ubuntu.com wrote: We can (and should) provide a spinny in the indicator icon itself during the transmit phase, and use a green or red flash (like the one you get during ajaxy updates in Launchpad) to indicate success or failure. I really like the idea of having some sort of notification on a successful broadcast from the memenu. However, I think that too much color could be a problem. Thus, I propose the following: - After the user stops writing the message, a spinner fades in at the right end of the textbox. - If the message is successfully sent, the spinner fades out, a check fades in, and after a while, the check fades out. - If the message fails to be sent, then a red cross fades in in place of the spinner, and doesn't fade out until the message is sent. - If it fails at first, but then works, the red x fades out, and the check fades in. I think that this system would provide a minimalistic notification of the broadcast, fitting in with the minimalistic style of the panel. ___ 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] Broadcasting from Me Menu: thoughts after some time using it
Is twitter, facebook etc not the same as a chat room or im'ing? Do their website interfaces not appear similar to a chat box? Why are they being treated different then chatting with someone? Sure status is global, but shouldn't twitter etc. just appear as contacts in your list? This way you don't have any of the problems listed here, plus you have a history of what you've said as well as others, just like when you use the website, or a chat box. http://haacked.com/archive/2007/06/02/twitter-solves-the-chat-usability-problem.aspx If you look at these services in this light, the only difference between them and a chat box is the nice backgrounds(? :D). Personally I'm much more curious about how the chat box could look similar to facebook etc. Because thats the best part about the services,..reading what other people have to say. ___ 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] Symbolic Folders - Icons for a better experience
On Mon, Jun 28, 2010 at 6:52 AM, Frederik Nnaji frederik.nn...@gmail.com wrote: here's 2 mockups of how a properly organized filesystem can look. ... anybody? I think this could be quite nice in a narrow domain (for instance provide a view of well known document types under ~/Documents). However I see several problems completely replacing the hierarchical view throughout the UI. The hierarchal view should always remain an option as long as the underlying file system is hierarchical. For example I would like to copy some related files of different types to a USB drive to be consumed on another system. How is this accomplished? Jumping between icons. And how are those relationships discovered (mp3 and album art)? Where are files displayed w then the type can not be easily determined or doesn't fit the available icons? Are all files all parsed to figure out where they should be displayed? This is costly (but of course an index could be maintained). I think a filter everything under directory xyz Nautilus view such as you illustrate would be great (but where would it start - perhaps it could only be for Documents). Also this view as a standard file open dialog used by apps would simplify things for end users and help bridge the way to an eventual non-hierarchal file system. However I don't agree that the hierarchal nature of current file systems should be totally hidden from users (or force them to terminal to do file management). Initially this should be a flat / symbolic view hosted in applications (and maybe a startup shell showing only a subset of home), and the user should be able to switch to a hierarchal view for browsing external media (or just if they want to). We're talking MVC here and this would be a great supplemental view in the file system model. ___ 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] Broadcasting from Me Menu: thoughts after some time using it
had to throw this out there before it slipped my mind, but one of the disadvantages to the design I proposed was that it takes a few to many clicks to tweet. Which is of course quite a problem considering the target audience and the typical urgency of the situation. However one of the beauties of having the contact list in the corner is it allows you to take advantage of the screen edge. Taking into consideration that an auto opened large contact list would be a problem, and that the cursor typically moves inward as you go down a list, one could simply trace from the corner down the edge of the screen to open the contacts (list). Further, having the the contact list sorted by favorites would make the Tweet contact not far off from the top as well as a swift one click open. Followed by a omg I just tried the bannana burger on In-n-outs secret menu!, it was amzing!!1! ___ 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-commits] [Merge] lp:~cjcurran/indicator-sound/metadata-tidyup into lp:indicator-sound
Conor Curran has proposed merging lp:~cjcurran/indicator-sound/metadata-tidyup
into lp:indicator-sound.
Requested reviews:
Indicator Applet Developers (indicator-applet-developers)
Formats the metadata text properly to comply with the spec.
--
https://code.launchpad.net/~cjcurran/indicator-sound/metadata-tidyup/+merge/28627
Your team ayatana-commits is subscribed to branch lp:indicator-sound.
=== modified file 'src/metadata-widget.c'
--- src/metadata-widget.c 2010-06-21 15:25:16 +
+++ src/metadata-widget.c 2010-06-28 12:33:31 +
@@ -57,6 +57,9 @@
GValue* value, gpointer userdata);
static void update_album_art(MetadataWidget* self);
+static void style_artist_text(MetadataWidget* self);
+static void style_title_text(MetadataWidget* self);
+static void style_album_text(MetadataWidget* self);
G_DEFINE_TYPE (MetadataWidget, metadata_widget, GTK_TYPE_MENU_ITEM);
@@ -88,32 +91,52 @@
GtkWidget *hbox;
- hbox = gtk_hbox_new(TRUE, 0);
+ hbox = gtk_hbox_new(FALSE, 0);
priv-hbox = hbox;
-
+
// image
priv-album_art = gtk_image_new();
priv-image_path = g_strdup(dbusmenu_menuitem_property_get(twin_item, DBUSMENU_METADATA_MENUITEM_ARTURL));
update_album_art(self);
+
gtk_box_pack_start (GTK_BOX (priv-hbox), priv-album_art, FALSE, FALSE, 0);
- GtkWidget* vbox = gtk_vbox_new(TRUE, 0);
+
+ GtkWidget* vbox = gtk_vbox_new(FALSE, 0);
+ gtk_container_set_border_width(GTK_CONTAINER(vbox), 10);
// artist
GtkWidget* artist;
- artist = gtk_label_new(dbusmenu_menuitem_property_get(twin_item, DBUSMENU_METADATA_MENUITEM_TEXT_ARTIST));
+ artist = gtk_label_new(dbusmenu_menuitem_property_get(twin_item,
+ DBUSMENU_METADATA_MENUITEM_TEXT_ARTIST));
+
+ gtk_misc_set_alignment(GTK_MISC(artist), (gfloat)0, (gfloat)0);
+ gtk_label_set_width_chars(GTK_LABEL(artist), 20);
+ gtk_label_set_ellipsize(GTK_LABEL(artist), PANGO_ELLIPSIZE_END);
priv-artist_label = artist;
-
+ // Style it up.
+ style_artist_text(self);
// piece
GtkWidget* piece;
- piece = gtk_label_new(dbusmenu_menuitem_property_get(twin_item, DBUSMENU_METADATA_MENUITEM_TEXT_TITLE));
+ piece = gtk_label_new(dbusmenu_menuitem_property_get(twin_item,
+ DBUSMENU_METADATA_MENUITEM_TEXT_TITLE));
+ gtk_misc_set_alignment(GTK_MISC(piece), (gfloat)0, (gfloat)0);
+ gtk_label_set_width_chars(GTK_LABEL(piece), 16);
+ gtk_label_set_ellipsize(GTK_LABEL(piece), PANGO_ELLIPSIZE_END);
priv-piece_label = piece;
-
+ // Style it up.
+ style_title_text(self);
// container
GtkWidget* container;
- container = gtk_label_new(dbusmenu_menuitem_property_get(twin_item, DBUSMENU_METADATA_MENUITEM_TEXT_ALBUM));
+ container = gtk_label_new(dbusmenu_menuitem_property_get(twin_item,
+ DBUSMENU_METADATA_MENUITEM_TEXT_ALBUM));
+ gtk_misc_set_alignment(GTK_MISC(container), (gfloat)0, (gfloat)0);
+ gtk_label_set_width_chars(GTK_LABEL(container), 20);
+ gtk_label_set_ellipsize(GTK_LABEL(container), PANGO_ELLIPSIZE_END);
priv-container_label = container;
+ // Style it up.
+ style_album_text(self);
// Pack in the right order
gtk_box_pack_start (GTK_BOX (vbox), priv-piece_label, FALSE, FALSE, 0);
@@ -170,27 +193,29 @@
if(g_ascii_strcasecmp(DBUSMENU_METADATA_MENUITEM_TEXT_ARTIST, property) == 0){
gtk_label_set_text(GTK_LABEL(priv-artist_label), g_value_get_string(value));
+ style_artist_text(mitem);
}
else if(g_ascii_strcasecmp(DBUSMENU_METADATA_MENUITEM_TEXT_TITLE, property) == 0){
- gtk_label_set_text(GTK_LABEL(priv-piece_label), g_value_get_string(value));
+ gtk_label_set_text(GTK_LABEL(priv-piece_label), g_value_get_string(value));
+ style_title_text(mitem);
}
else if(g_ascii_strcasecmp(DBUSMENU_METADATA_MENUITEM_TEXT_ALBUM, property) == 0){
gtk_label_set_text(GTK_LABEL(priv-container_label), g_value_get_string(value));
+ style_album_text(mitem);
}
else if(g_ascii_strcasecmp(DBUSMENU_METADATA_MENUITEM_ARTURL, property) == 0){
if(priv-image_path != NULL){
g_free(priv-image_path);
}
-
priv-image_path = g_value_dup_string(value);
-
if(priv-image_path != NULL){
update_album_art(mitem);
}
}
}
-static void update_album_art(MetadataWidget* self){
+static void
+update_album_art(MetadataWidget* self){
MetadataWidgetPrivate * priv = METADATA_WIDGET_GET_PRIVATE(self);
GdkPixbuf* pixbuf;
pixbuf = gdk_pixbuf_new_from_file(priv-image_path, NULL);
@@ -200,6 +225,41 @@
g_object_unref(pixbuf);
}
+// TODO refactor next 3 methods into one once the style has been
+// signed off by design
+static void
+style_artist_text(MetadataWidget* self)
+{
+ MetadataWidgetPrivate * priv = METADATA_WIDGET_GET_PRIVATE(self);
+ char* markup;
+ markup = g_markup_printf_escaped (span size=\small\%s/span,
+ gtk_label_get_text(GTK_LABEL(priv-artist_label)));
+
Re: [Ayatana-commits] [Merge] lp:~cjcurran/indicator-sound/metadata-tidyup into lp:indicator-sound
Review: Approve Looks good to me. Approved. -- https://code.launchpad.net/~cjcurran/indicator-sound/metadata-tidyup/+merge/28627 Your team ayatana-commits is subscribed to branch lp:indicator-sound. ___ Mailing list: https://launchpad.net/~ayatana-commits Post to : ayatana-commits@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana-commits More help : https://help.launchpad.net/ListHelp
[Ayatana-commits] [Merge] lp:~cjcurran/indicator-sound/metadata-tidyup into lp:indicator-sound
The proposal to merge lp:~cjcurran/indicator-sound/metadata-tidyup into lp:indicator-sound has been updated. Status: Needs review = Merged -- https://code.launchpad.net/~cjcurran/indicator-sound/metadata-tidyup/+merge/28627 Your team ayatana-commits is subscribed to branch lp:indicator-sound. ___ Mailing list: https://launchpad.net/~ayatana-commits Post to : ayatana-commits@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana-commits More help : https://help.launchpad.net/ListHelp
[Ayatana-commits] [Merge] lp:~ted/dbusmenu/dumping-our-values into lp:dbusmenu
Ted Gould has proposed merging lp:~ted/dbusmenu/dumping-our-values into
lp:dbusmenu.
Requested reviews:
DBus Menu Team (dbusmenu-team)
Make the dumper handle values better. Including collections and STRV lists.
--
https://code.launchpad.net/~ted/dbusmenu/dumping-our-values/+merge/28655
Your team ayatana-commits is subscribed to branch lp:dbusmenu.
=== modified file 'tools/dbusmenu-dumper.c'
--- tools/dbusmenu-dumper.c 2009-12-15 20:35:08 +
+++ tools/dbusmenu-dumper.c 2010-06-28 17:09:26 +
@@ -25,8 +25,100 @@
#include libdbusmenu-glib/client.h
#include libdbusmenu-glib/menuitem.h
+#include dbus/dbus-gtype-specialized.h
+
static GMainLoop * mainloop = NULL;
+static gchar * value2string (const GValue * value, int depth);
+
+static gchar *
+strv_dumper(const GValue * value)
+{
+ gchar ** strv = (gchar **)g_value_get_boxed(value);
+
+ gchar * joined = g_strjoinv(\, \, strv);
+ gchar * retval = g_strdup_printf([\%s\], joined);
+ g_free(joined);
+ return retval;
+}
+
+typedef struct _collection_iterator_t collection_iterator_t;
+struct _collection_iterator_t {
+ gchar * space;
+ GPtrArray * array;
+ gboolean first;
+ int depth;
+};
+
+static void
+collection_iterate (const GValue * value, gpointer user_data)
+{
+ collection_iterator_t * iter = (collection_iterator_t *)user_data;
+
+ gchar * str = value2string(value, iter-depth);
+ gchar * retval = NULL;
+
+ if (iter-first) {
+ iter-first = FALSE;
+ retval = g_strdup_printf(\n%s%s, iter-space, str);
+ } else {
+ retval = g_strdup_printf(,\n%s%s, iter-space, str);
+ }
+
+ g_ptr_array_add(iter-array, retval);
+ g_free(str);
+
+ return;
+}
+
+static gchar *
+collection_dumper (const GValue * value, int depth)
+{
+ gchar * space = g_strnfill(depth, ' ');
+ GPtrArray * array = g_ptr_array_new_with_free_func(g_free);
+
+ g_ptr_array_add(array, g_strdup([));
+
+ collection_iterator_t iter;
+ iter.space = space;
+ iter.array = array;
+ iter.first = TRUE;
+ iter.depth = depth + 2;
+
+ dbus_g_type_collection_value_iterate(value, collection_iterate, iter);
+
+ g_ptr_array_add(array, g_strdup_printf(\n%s], space));
+
+ g_free(space);
+
+ gchar * retstr = NULL;
+ if (array-len == 3) {
+ retstr = g_strdup_printf([%s], ((gchar *)array-pdata[1]) + depth + 1/*for newline*/);
+ } else {
+ retstr = g_strjoinv(NULL, (gchar **)array-pdata);
+ }
+
+ g_ptr_array_free(array, TRUE);
+
+ return retstr;
+}
+
+static gchar *
+value2string (const GValue * value, int depth)
+{
+ gchar * str = NULL;
+
+ if (dbus_g_type_is_collection(G_VALUE_TYPE(value))) {
+ str = collection_dumper(value, depth);
+ } else if (G_VALUE_TYPE(value) == G_TYPE_STRV) {
+ str = strv_dumper(value);
+ } else {
+ str = g_strdup_value_contents(value);
+ }
+
+ return str;
+}
+
static void
print_menuitem (DbusmenuMenuitem * item, int depth)
{
@@ -36,11 +128,10 @@
GList * properties = dbusmenu_menuitem_properties_list(item);
GList * property;
for (property = properties; property != NULL; property = g_list_next(property)) {
- GValue value = {0};
- g_value_init(value, G_TYPE_STRING);
- g_value_transform(dbusmenu_menuitem_property_get_value(item, (gchar *)property-data), value);
- g_print(,\n%s\%s\: \%s\, space, (gchar *)property-data, g_value_get_string(value));
- g_value_unset(value);
+ const GValue * value = dbusmenu_menuitem_property_get_value(item, (gchar *)property-data);
+ gchar * str = value2string(value, depth + g_utf8_strlen((gchar *)property-data, -1) + 2 /*quotes*/ + 2 /*: */);
+ g_print(,\n%s\%s\: %s, space, (gchar *)property-data, str);
+ g_free(str);
}
g_list_free(properties);
___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help : https://help.launchpad.net/ListHelp
Re: [Ayatana-commits] [Merge] lp:~ted/dbusmenu/dumping-our-values into lp:dbusmenu
Review: Approve Cool. I take it that null is a legitimate value, functions on the value2string seem to handle that well. +1 -- https://code.launchpad.net/~ted/dbusmenu/dumping-our-values/+merge/28655 Your team ayatana-commits is subscribed to branch lp:dbusmenu. ___ Mailing list: https://launchpad.net/~ayatana-commits Post to : ayatana-commits@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana-commits More help : https://help.launchpad.net/ListHelp
[Ayatana-commits] [Branch ~dbusmenu-team/dbusmenu/trunk] Rev 123: Ignoring the gtk-doc build files.
revno: 123 committer: Ted Gould t...@gould.cx branch nick: trunk timestamp: Mon 2010-06-28 12:58:36 -0500 message: Ignoring the gtk-doc build files. modified: .bzrignore -- lp:dbusmenu https://code.launchpad.net/~dbusmenu-team/dbusmenu/trunk Your team ayatana-commits is subscribed to branch lp:dbusmenu. To unsubscribe from this branch go to https://code.launchpad.net/~dbusmenu-team/dbusmenu/trunk/+edit-subscription === modified file '.bzrignore' --- .bzrignore 2010-06-21 19:47:08 + +++ .bzrignore 2010-06-28 17:58:36 + @@ -80,3 +80,105 @@ tests/test-glib-submenu tests/test-glib-submenu-client tests/test-glib-submenu-server +docs/libdbusmenu-glib/reference/html-build.stamp +docs/libdbusmenu-glib/reference/html.stamp +docs/libdbusmenu-glib/reference/libdbusmenu-glib-decl-list.txt +docs/libdbusmenu-glib/reference/libdbusmenu-glib-decl-list.txt.bak +docs/libdbusmenu-glib/reference/libdbusmenu-glib-decl.txt +docs/libdbusmenu-glib/reference/libdbusmenu-glib-decl.txt.bak +docs/libdbusmenu-glib/reference/libdbusmenu-glib-overrides.txt +docs/libdbusmenu-glib/reference/libdbusmenu-glib-undeclared.txt +docs/libdbusmenu-glib/reference/libdbusmenu-glib-undocumented.txt +docs/libdbusmenu-glib/reference/libdbusmenu-glib-unused.txt +docs/libdbusmenu-glib/reference/libdbusmenu-glib.args +docs/libdbusmenu-glib/reference/libdbusmenu-glib.hierarchy +docs/libdbusmenu-glib/reference/libdbusmenu-glib.interfaces +docs/libdbusmenu-glib/reference/libdbusmenu-glib.prerequisites +docs/libdbusmenu-glib/reference/libdbusmenu-glib.signals +docs/libdbusmenu-glib/reference/scan-build.stamp +docs/libdbusmenu-glib/reference/sgml-build.stamp +docs/libdbusmenu-glib/reference/sgml.stamp +docs/libdbusmenu-glib/reference/tmpl-build.stamp +docs/libdbusmenu-glib/reference/tmpl.stamp +docs/libdbusmenu-glib/reference/version.xml +docs/libdbusmenu-glib/reference/xml +docs/libdbusmenu-glib/reference/html/annotation-glossary.html +docs/libdbusmenu-glib/reference/html/api-index-full.html +docs/libdbusmenu-glib/reference/html/ch01.html +docs/libdbusmenu-glib/reference/html/home.png +docs/libdbusmenu-glib/reference/html/index.html +docs/libdbusmenu-glib/reference/html/index.sgml +docs/libdbusmenu-glib/reference/html/left.png +docs/libdbusmenu-glib/reference/html/libdbusmenu-glib-DbusmenuClient.html +docs/libdbusmenu-glib/reference/html/libdbusmenu-glib-DbusmenuClientMenuitem.html +docs/libdbusmenu-glib/reference/html/libdbusmenu-glib-DbusmenuMenuitem.html +docs/libdbusmenu-glib/reference/html/libdbusmenu-glib-DbusmenuMenuitemProxy.html +docs/libdbusmenu-glib/reference/html/libdbusmenu-glib-DbusmenuServer.html +docs/libdbusmenu-glib/reference/html/libdbusmenu-glib.devhelp +docs/libdbusmenu-glib/reference/html/libdbusmenu-glib.devhelp2 +docs/libdbusmenu-glib/reference/html/object-tree.html +docs/libdbusmenu-glib/reference/html/right.png +docs/libdbusmenu-glib/reference/html/style.css +docs/libdbusmenu-glib/reference/html/up.png +docs/libdbusmenu-glib/reference/tmpl/client-menuitem.sgml +docs/libdbusmenu-glib/reference/tmpl/client-menuitem.sgml.bak +docs/libdbusmenu-glib/reference/tmpl/client.sgml +docs/libdbusmenu-glib/reference/tmpl/client.sgml.bak +docs/libdbusmenu-glib/reference/tmpl/libdbusmenu-glib-unused.sgml +docs/libdbusmenu-glib/reference/tmpl/menuitem-proxy.sgml +docs/libdbusmenu-glib/reference/tmpl/menuitem-proxy.sgml.bak +docs/libdbusmenu-glib/reference/tmpl/menuitem.sgml +docs/libdbusmenu-glib/reference/tmpl/menuitem.sgml.bak +docs/libdbusmenu-glib/reference/tmpl/server.sgml +docs/libdbusmenu-glib/reference/tmpl/server.sgml.bak +docs/libdbusmenu-gtk/reference/html-build.stamp +docs/libdbusmenu-gtk/reference/html.stamp +docs/libdbusmenu-gtk/reference/libdbusmenu-gtk-decl-list.txt +docs/libdbusmenu-gtk/reference/libdbusmenu-gtk-decl-list.txt.bak +docs/libdbusmenu-gtk/reference/libdbusmenu-gtk-decl.txt +docs/libdbusmenu-gtk/reference/libdbusmenu-gtk-decl.txt.bak +docs/libdbusmenu-gtk/reference/libdbusmenu-gtk-overrides.txt +docs/libdbusmenu-gtk/reference/libdbusmenu-gtk-sections.txt +docs/libdbusmenu-gtk/reference/libdbusmenu-gtk-undeclared.txt +docs/libdbusmenu-gtk/reference/libdbusmenu-gtk-undocumented.txt +docs/libdbusmenu-gtk/reference/libdbusmenu-gtk-unused.txt +docs/libdbusmenu-gtk/reference/libdbusmenu-gtk.args +docs/libdbusmenu-gtk/reference/libdbusmenu-gtk.hierarchy +docs/libdbusmenu-gtk/reference/libdbusmenu-gtk.interfaces +docs/libdbusmenu-gtk/reference/libdbusmenu-gtk.prerequisites +docs/libdbusmenu-gtk/reference/libdbusmenu-gtk.signals +docs/libdbusmenu-gtk/reference/libdbusmenu-gtk.types +docs/libdbusmenu-gtk/reference/scan-build.stamp +docs/libdbusmenu-gtk/reference/sgml-build.stamp +docs/libdbusmenu-gtk/reference/sgml.stamp +docs/libdbusmenu-gtk/reference/tmpl-build.stamp +docs/libdbusmenu-gtk/reference/tmpl.stamp +docs/libdbusmenu-gtk/reference/version.xml +docs/libdbusmenu-gtk/reference/xml +docs/libdbusmenu-gtk/reference/html/Genericmenuitem.html
[Ayatana-commits] [Branch ~dbusmenu-team/dbusmenu/trunk] Rev 122: Updating dbusmenu-dumper to handle collections better
Merge authors:
Ted Gould (ted)
Related merge proposals:
https://code.launchpad.net/~ted/dbusmenu/dumping-our-values/+merge/28655
proposed by: Ted Gould (ted)
review: Approve - David Barth (dbarth)
revno: 122 [merge]
committer: Ted Gould t...@gould.cx
branch nick: trunk
timestamp: Mon 2010-06-28 12:57:07 -0500
message:
Updating dbusmenu-dumper to handle collections better
modified:
tools/dbusmenu-dumper.c
--
lp:dbusmenu
https://code.launchpad.net/~dbusmenu-team/dbusmenu/trunk
Your team ayatana-commits is subscribed to branch lp:dbusmenu.
To unsubscribe from this branch go to
https://code.launchpad.net/~dbusmenu-team/dbusmenu/trunk/+edit-subscription
=== modified file 'tools/dbusmenu-dumper.c'
--- tools/dbusmenu-dumper.c 2009-12-15 20:35:08 +
+++ tools/dbusmenu-dumper.c 2010-06-28 17:55:51 +
@@ -25,8 +25,104 @@
#include libdbusmenu-glib/client.h
#include libdbusmenu-glib/menuitem.h
+#include dbus/dbus-gtype-specialized.h
+
static GMainLoop * mainloop = NULL;
+static gchar * value2string (const GValue * value, int depth);
+
+static gchar *
+strv_dumper(const GValue * value)
+{
+ gchar ** strv = (gchar **)g_value_get_boxed(value);
+
+ gchar * joined = g_strjoinv(\, \, strv);
+ gchar * retval = g_strdup_printf([\%s\], joined);
+ g_free(joined);
+ return retval;
+}
+
+typedef struct _collection_iterator_t collection_iterator_t;
+struct _collection_iterator_t {
+ gchar * space;
+ GPtrArray * array;
+ gboolean first;
+ int depth;
+};
+
+static void
+collection_iterate (const GValue * value, gpointer user_data)
+{
+ collection_iterator_t * iter = (collection_iterator_t *)user_data;
+
+ gchar * str = value2string(value, iter-depth);
+ gchar * retval = NULL;
+
+ if (iter-first) {
+ iter-first = FALSE;
+ retval = g_strdup_printf(\n%s%s, iter-space, str);
+ } else {
+ retval = g_strdup_printf(,\n%s%s, iter-space, str);
+ }
+
+ g_ptr_array_add(iter-array, retval);
+ g_free(str);
+
+ return;
+}
+
+static gchar *
+collection_dumper (const GValue * value, int depth)
+{
+ gchar * space = g_strnfill(depth, ' ');
+ GPtrArray * array = g_ptr_array_new_with_free_func(g_free);
+
+ g_ptr_array_add(array, g_strdup([));
+
+ collection_iterator_t iter;
+ iter.space = space;
+ iter.array = array;
+ iter.first = TRUE;
+ iter.depth = depth + 2;
+
+ dbus_g_type_collection_value_iterate(value, collection_iterate, iter);
+
+ g_ptr_array_add(array, g_strdup_printf(\n%s], space));
+
+ g_free(space);
+
+ gchar * retstr = NULL;
+ if (array-len == 3) {
+ retstr = g_strdup_printf([%s], ((gchar *)array-pdata[1]) + depth + 1/*for newline*/);
+ } else {
+ retstr = g_strjoinv(NULL, (gchar **)array-pdata);
+ }
+
+ g_ptr_array_free(array, TRUE);
+
+ return retstr;
+}
+
+static gchar *
+value2string (const GValue * value, int depth)
+{
+ gchar * str = NULL;
+
+ if (value == NULL) {
+ return g_strdup((null));
+ }
+
+ if (dbus_g_type_is_collection(G_VALUE_TYPE(value))) {
+ str = collection_dumper(value, depth);
+ } else if (G_VALUE_TYPE(value) == G_TYPE_STRV) {
+ str = strv_dumper(value);
+ } else {
+ str = g_strdup_value_contents(value);
+ }
+
+ return str;
+}
+
static void
print_menuitem (DbusmenuMenuitem * item, int depth)
{
@@ -36,11 +132,10 @@
GList * properties = dbusmenu_menuitem_properties_list(item);
GList * property;
for (property = properties; property != NULL; property = g_list_next(property)) {
- GValue value = {0};
- g_value_init(value, G_TYPE_STRING);
- g_value_transform(dbusmenu_menuitem_property_get_value(item, (gchar *)property-data), value);
- g_print(,\n%s\%s\: \%s\, space, (gchar *)property-data, g_value_get_string(value));
- g_value_unset(value);
+ const GValue * value = dbusmenu_menuitem_property_get_value(item, (gchar *)property-data);
+ gchar * str = value2string(value, depth + g_utf8_strlen((gchar *)property-data, -1) + 2 /*quotes*/ + 2 /*: */);
+ g_print(,\n%s\%s\: %s, space, (gchar *)property-data, str);
+ g_free(str);
}
g_list_free(properties);
___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help : https://help.launchpad.net/ListHelp
[Ayatana-commits] [Merge] lp:~ted/dbusmenu/dumping-our-values into lp:dbusmenu
The proposal to merge lp:~ted/dbusmenu/dumping-our-values into lp:dbusmenu has been updated. Status: Needs review = Merged -- https://code.launchpad.net/~ted/dbusmenu/dumping-our-values/+merge/28655 Your team ayatana-commits is subscribed to branch lp:dbusmenu. ___ Mailing list: https://launchpad.net/~ayatana-commits Post to : ayatana-commits@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana-commits More help : https://help.launchpad.net/ListHelp
[Ayatana-commits] [Merge] lp:~bratsche/appmenu-gtk/rebuild-on-attach into lp:appmenu-gtk
Cody Russell has proposed merging lp:~bratsche/appmenu-gtk/rebuild-on-attach
into lp:appmenu-gtk.
Requested reviews:
Canonical Desktop Experience Team (canonical-dx-team)
This will have no noticeable effect until my gtk+ patch gets merged into
Ubuntu. seb128 said he'll do that in the morning.
That gtk+ patch combined with this new revision will fix all remaining issues
with missing menuitems and, I believe, with menuitems being out of order.
--
https://code.launchpad.net/~bratsche/appmenu-gtk/rebuild-on-attach/+merge/28681
Your team ayatana-commits is subscribed to branch lp:appmenu-gtk.
=== modified file 'src/bridge.c'
--- src/bridge.c 2010-06-25 17:45:25 +
+++ src/bridge.c 2010-06-28 20:45:43 +
@@ -771,6 +771,12 @@
bridge);
return;
}
+ else
+{
+ toplevel = gtk_widget_get_toplevel (attach);
+
+ rebuild_window_items (bridge, toplevel);
+}
}
if (GTK_IS_WINDOW (toplevel))
___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help : https://help.launchpad.net/ListHelp
Re: [Ayatana-commits] [Merge] lp:~bratsche/appmenu-gtk/rebuild-on-attach into lp:appmenu-gtk
Review: Approve
So excited!
review approve
On Mon, 2010-06-28 at 20:45 +, Cody Russell wrote:
Cody Russell has proposed merging lp:~bratsche/appmenu-gtk/rebuild-on-attach
into lp:appmenu-gtk.
Requested reviews:
Canonical Desktop Experience Team (canonical-dx-team)
This will have no noticeable effect until my gtk+ patch gets merged into
Ubuntu. seb128 said he'll do that in the morning.
That gtk+ patch combined with this new revision will fix all remaining issues
with missing menuitems and, I believe, with menuitems being out of order.
differences between files attachment (review-diff.txt)
=== modified file 'src/bridge.c'
--- src/bridge.c 2010-06-25 17:45:25 +
+++ src/bridge.c 2010-06-28 20:45:43 +
@@ -771,6 +771,12 @@
bridge);
return;
}
+ else
+{
+ toplevel = gtk_widget_get_toplevel (attach);
+
+ rebuild_window_items (bridge, toplevel);
+}
}
if (GTK_IS_WINDOW (toplevel))
--
https://code.launchpad.net/~bratsche/appmenu-gtk/rebuild-on-attach/+merge/28681
Your team ayatana-commits is subscribed to branch lp:appmenu-gtk.
___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help : https://help.launchpad.net/ListHelp
[Ayatana-commits] [Merge] lp:~bratsche/appmenu-gtk/rebuild-on-attach into lp:appmenu-gtk
The proposal to merge lp:~bratsche/appmenu-gtk/rebuild-on-attach into lp:appmenu-gtk has been updated. Status: Needs review = Merged -- https://code.launchpad.net/~bratsche/appmenu-gtk/rebuild-on-attach/+merge/28681 Your team ayatana-commits is subscribed to branch lp:appmenu-gtk. ___ Mailing list: https://launchpad.net/~ayatana-commits Post to : ayatana-commits@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana-commits More help : https://help.launchpad.net/ListHelp
