Re: the next step on the desktop
Hi all, Sorry, I forgot to write who wrote which quote... 1 On the horizontal application launchers While the horizontal format is fine for a few icon-only launchers (quick launch, docks etc.), the idea to Have it open a horizontal menu that replaces or covers the panel entirely. This menu would show a list of your applications folders, as well as is bad for the following reasons: 1.1. we (RTL and LTR writing humans :) ) are used to read horizontal text sequentially - from the beginning to the end, like a single paragraph, not to separate it in stacks. With vertically separated items, we can easily find the beginning of each one, like multiple paragraphs. (finding the third parahraph in a page is much easier than finding the third sentence) 1.2. Since the items are horizontal, in order to move the mouse from the first item to the last, you need to travel much more than you need to with vertical lists. 1.3 Due to the same reason as 1.2, you can fit less items in a row than in a column (even when the width of a screen is much bigger than its height) 2. On covering the work Like the application launcher, it opens horizontally rather than vertically (so it doesn't cover what you are working on) I actually like the concept behind this, but I fail to see the importance of it. If you want to start a new application, it is going to open in front of your current work anyway, so why shouldn't the launcher? 3. On the taskbar text I've used smooth tasks applet which hides the text. While it *looks* awesome, it fails when you have multiple windows from the same application (Gimp, Inkscape, OOo etc.) - you need to hover the items, to get the text and the window thumbnail in order to activate one of them. 4. On 'verticalness' of it all :) In any kind of Vertical launch menu (Windows* kde3, Kickoff, Lancelot) you have a longer number of step to do before you find whatever you want This has nothing to do with something being vertical, or horizontal. It is about 'popup' launchers. As you can see here: http://imagebin.org/135938 you can have a vertical (with autohide for example) panel launcher that is as accessible as a dock Cheerio all! -- You don't stop laughing because you grow old. You grow old because you stop laughing. -- Michael Pritchard ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
New properties for StatusNotifierItem: Accessible Label (1/3)
Hello, For an intro see the mail with the (0/3) in the subject line. One of the projects we're doing is to try and make Unity more accessible. To that end we'd like to add properties to add accessible labels for the icons that could be given to screen readers. We're planning on issuing warnings if an icon is set without an accessible label, it would be great if the KDE object could do the same. Here are the properties that we're thinking about: IconAccessibleLabel and AttentionAccessibleLabel. They should be strings describing the icons/movies, localized and change with the icon. An example would be Battery 45%. --Ted PS - I don't think that OverlayAccessibleLabel makes sense, but I'd love to hear people's comments on that. signature.asc Description: This is a digitally signed message part ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
New properties for StatusNotifierItem (0/3)
Hello, I'd like to propose some new properties to be added to the SNI interface for a couple of projects in the Application Indicator framework that we have over here. We'd love it if you guys would consider adopting them in the base spec. Also, if you have comments on how to make them better I would love to know that as well. I haven't implemented anything in this mail at this point. I'm going to go ahead and put them in a set of mails so that each feature can be discussed in a separate thread. Sorry for all the mails but I think it'll keep the discussion more organized. Also, I'm not subscribed to plasma-devel so please CC me on replies. --Ted signature.asc Description: This is a digitally signed message part ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
New properties for StatusNotifierItem: (Not|Only)ShowIn (2/3)
Hello, For an intro see the mail with the (0/3) in the subject line. We also started to use some of the application indicators from applications in the launcher on the left side of the screen. We use the application indicator to provide additional menus for the launcher which we call a quick list. We're currently choosing which application is on the panel and which is in the launcher based on heuristics, but we'd like to have a way for applications to explicitly control that behavior if they so desire. What we'd like to add is two properties that are lists of strings: NotShowIn and OnlyShowIn. These would work exactly the same as the same properties in Desktop files where an application could say NotShowIn=[Unity Launcher] and ensure that they'd never end up with that item used as a quicklist. Most applications would hopefully not find a reason to use this, but for those that would like the precise control it would be available. --Ted signature.asc Description: This is a digitally signed message part ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
New properties for StatusNotifierItem: Desktop Key (3/3)
Hello, For an intro see the mail with the (0/3) in the subject line. We'd like to suggest an additional key for .desktop files that lists the IDs of Status Notifier Items that an application exports. This will allow us to better match SNI items when we are using them as quicklists, as errors are very embarrassing ;) For this key we're suggesting: X-KDE-StatusNotifierItems which would be a list of strings. --Ted signature.asc Description: This is a digitally signed message part ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem (0/3)
On Thursday 03 February 2011, Ted Gould wrote: Hello, I'd like to propose some new properties to be added to the SNI interface for a couple of projects in the Application Indicator framework that we have over here. We'd love it if you guys would consider adopting them in the base spec. Also, if you have comments on how to make them better I would love to know that as well. I haven't implemented anything in this mail at this point. I'm going to go ahead and put them in a set of mails so that each feature can be discussed in a separate thread. Sorry for all the mails but I think it'll keep the discussion more organized. Also, I'm not subscribed to plasma-devel so please CC me on replies. Hi, Good there is still interest. this should be really be revived in freedesktop. I think now among kde and ubuntu and the app using it could be wide enough, i would *really* like to trnsition to org.freedesktop.* bus names and call the spec 1.0 My comments on the proposals themselves in the next mails Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
On Thursday 03 February 2011, Ted Gould wrote: Hello, For an intro see the mail with the (0/3) in the subject line. One of the projects we're doing is to try and make Unity more accessible. To that end we'd like to add properties to add accessible labels for the icons that could be given to screen readers. We're planning on issuing warnings if an icon is set without an accessible label, it would be great if the KDE object could do the same. Here are the properties that we're thinking about: IconAccessibleLabel and AttentionAccessibleLabel. They should be strings describing the icons/movies, localized and change with the icon. An example would be Battery 45%. --Ted PS - I don't think that OverlayAccessibleLabel makes sense, but I'd love to hear people's comments on that. This is a really good idea, let's analyze it. Basically, what the normal icon, the attention icon and the overlay indicate is a status, someting descriptive about what's going on (let's say battery 45%) now, we have a text representation, and that is what's written in the tooltip. this may or may not be enough for a screenreader to represent it textually... so, we could have a staus for normal and active, always exposed to the bus, or a status text that is always the current, that is updated from the application, (and also when the icon status changes from normal to requestingattention for instance) so a TextualStatus property could be enough... ideas? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: (Not|Only)ShowIn (2/3)
On Thursday 03 February 2011, Ted Gould wrote: Hello, For an intro see the mail with the (0/3) in the subject line. We also started to use some of the application indicators from applications in the launcher on the left side of the screen. We use the application indicator to provide additional menus for the launcher which we call a quick list. We're currently choosing which application is on the panel and which is in the launcher based on heuristics, but we'd like to have a way for applications to explicitly control that behavior if they so desire. What we'd like to add is two properties that are lists of strings: NotShowIn and OnlyShowIn. These would work exactly the same as the same properties in Desktop files where an application could say NotShowIn=[Unity Launcher] and ensure that they'd never end up with that item used as a quicklist. Most applications would hopefully not find a reason to use this, but for those that would like the precise control it would be available. --Ted I'm a bit hesitant about this, I'm not sure should be up to the application knowing where it should be or not present... what is an exact use case? what is that unity needs to show or not show? wouldn't be possible to gather from the data like the category of the item (or even add more description data of what the item is about)? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Desktop Key (3/3)
On Thursday 03 February 2011, Ted Gould wrote: Hello, For an intro see the mail with the (0/3) in the subject line. We'd like to suggest an additional key for .desktop files that lists the IDs of Status Notifier Items that an application exports. This will allow us to better match SNI items when we are using them as quicklists, as errors are very embarrassing ;) For this key we're suggesting: X-KDE-StatusNotifierItems which would be a list of strings. --Ted I think I like this. this goes well with our idea of merging the taskbar and the status notifier item as well. could still be a bit error prone, but i can't think of more automatic ways. it could also be done on the other way around, by having a list of desktop file paths as a property of the notifier item, but wouldn't be better I think... Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Add option to qalculate to show the result in different bases at the same time
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100533/ --- Review request for Plasma. Summary --- Add the option to qalculate to show the result in binary, octal, decimal and hexadecimal at the same time. This only works if the result is an integer Diffs - applets/qalculate/qalculate_settings.h cab44e9 applets/qalculate/qalculate_settings.cpp b317e67 applets/qalculate/qalculate_labels.cpp b04c538 applets/qalculate/qalculate_engine.cpp 708f3b2 applets/qalculate/qalculate_labels.h 4cf31e2 Diff: http://git.reviewboard.kde.org/r/100533/diff Testing --- built and tested the applet Screenshots --- settings http://git.reviewboard.kde.org/r/100533/s/63/ result http://git.reviewboard.kde.org/r/100533/s/64/ Thanks, Jef ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem (0/3)
On Thu, 2011-02-03 at 14:27 +0100, Marco Martin wrote: On Thursday 03 February 2011, Ted Gould wrote: I'd like to propose some new properties to be added to the SNI interface for a couple of projects in the Application Indicator framework that we have over here. We'd love it if you guys would consider adopting them in the base spec. Also, if you have comments on how to make them better I would love to know that as well. I haven't implemented anything in this mail at this point. I'm going to go ahead and put them in a set of mails so that each feature can be discussed in a separate thread. Sorry for all the mails but I think it'll keep the discussion more organized. Also, I'm not subscribed to plasma-devel so please CC me on replies. Good there is still interest. this should be really be revived in freedesktop. I think now among kde and ubuntu and the app using it could be wide enough, i would *really* like to trnsition to org.freedesktop.* bus names and call the spec 1.0 I'm +1 on this. I don't believe the GNOME Shell guys will be willing to pick it up though. But, I think that enough people are using it, even if it's not everyone, it is worth putting it in a standard place. --Ted signature.asc Description: This is a digitally signed message part ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
On Thu, 2011-02-03 at 14:37 +0100, Marco Martin wrote: On Thursday 03 February 2011, Ted Gould wrote: One of the projects we're doing is to try and make Unity more accessible. To that end we'd like to add properties to add accessible labels for the icons that could be given to screen readers. We're planning on issuing warnings if an icon is set without an accessible label, it would be great if the KDE object could do the same. Here are the properties that we're thinking about: IconAccessibleLabel and AttentionAccessibleLabel. They should be strings describing the icons/movies, localized and change with the icon. An example would be Battery 45%. --Ted PS - I don't think that OverlayAccessibleLabel makes sense, but I'd love to hear people's comments on that. This is a really good idea, let's analyze it. Basically, what the normal icon, the attention icon and the overlay indicate is a status, someting descriptive about what's going on (let's say battery 45%) now, we have a text representation, and that is what's written in the tooltip. this may or may not be enough for a screenreader to represent it textually... Yeah, in talking to the a11y folks they like tooltips, but they really wanted another label as sometimes the tooltips don't describe the icon enough for a blind user to know what it means. Apparently screen readers can distinguish and make tooltips additional information as well. Also, sometimes tooltips can be too complex for screen readers to do a good job with them. so, we could have a staus for normal and active, always exposed to the bus, or a status text that is always the current, that is updated from the application, (and also when the icon status changes from normal to requestingattention for instance) so a TextualStatus property could be enough... ideas? I thought about this, and I think that in general, this works as well. But it seemed to me that it didn't align with the spirit of the spec in that if we're describing icons, we should describe the icons in the way that they're represented on DBus. --Ted signature.asc Description: This is a digitally signed message part ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: (Not|Only)ShowIn (2/3)
On Thu, 2011-02-03 at 14:41 +0100, Marco Martin wrote: On Thursday 03 February 2011, Ted Gould wrote: We also started to use some of the application indicators from applications in the launcher on the left side of the screen. We use the application indicator to provide additional menus for the launcher which we call a quick list. We're currently choosing which application is on the panel and which is in the launcher based on heuristics, but we'd like to have a way for applications to explicitly control that behavior if they so desire. What we'd like to add is two properties that are lists of strings: NotShowIn and OnlyShowIn. These would work exactly the same as the same properties in Desktop files where an application could say NotShowIn=[Unity Launcher] and ensure that they'd never end up with that item used as a quicklist. Most applications would hopefully not find a reason to use this, but for those that would like the precise control it would be available. I'm a bit hesitant about this, I'm not sure should be up to the application knowing where it should be or not present... what is an exact use case? what is that unity needs to show or not show? wouldn't be possible to gather from the data like the category of the item (or even add more description data of what the item is about)? The use case was people wanting different menus on the panel vs. on the launcher. Or not appearing on the panel at all even if there wasn't a launcher available. So the specific case was with Tomboy where in the menu on the panel they wanted to have a Quit button but the launcher menu automatically has a close (through the WM) and they didn't want both. Also, in our specific case there are more restrictions on the menus in the launcher (no submenus) so if an app wanted to use those they wouldn't want it to appear in the launcher. I would imagine that for most applications if they were going to use this feature they would be building more than one Item. They'd build one for a very specific visual target and then another that is a generic item for all other visualizations. --Ted signature.asc Description: This is a digitally signed message part ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Desktop Key (3/3)
On Thu, 2011-02-03 at 14:45 +0100, Marco Martin wrote: On Thursday 03 February 2011, Ted Gould wrote: We'd like to suggest an additional key for .desktop files that lists the IDs of Status Notifier Items that an application exports. This will allow us to better match SNI items when we are using them as quicklists, as errors are very embarrassing ;) For this key we're suggesting: X-KDE-StatusNotifierItems which would be a list of strings. I think I like this. this goes well with our idea of merging the taskbar and the status notifier item as well. could still be a bit error prone, but i can't think of more automatic ways. it could also be done on the other way around, by having a list of desktop file paths as a property of the notifier item, but wouldn't be better I think... Yeah, it's not impossible to have errors. We hope that distro's would be able to police that some though (and distro patch appropriately). Perhaps a naming guide would be appropriate so there is less conflict? WRT the desktop file being a property I like that too. The only caveat is that with libindicate we did that, and we've gotten a surprising amount of push back from developers. I'm really unclear on why, but they don't like having the path to the desktop file in their code. I honestly think they're being irrational, but just to let you know there is some concern there. --Ted signature.asc Description: This is a digitally signed message part ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add option to qalculate to show the result in different bases at the same time
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100533/#review1178 --- Ship it! Except for one comment, it looks fine. Can you commit the patch yourself? applets/qalculate/qalculate_labels.h http://git.reviewboard.kde.org/r/100533/#comment984 I don't understand why you created the AppletSettings class. Wouldn't it be easier to simply pass a pointer to QalculateSettings in the constructor? This would save some code duplication. Or am I missing something? - Matteo On Feb. 3, 2011, 2:09 p.m., Jef Steelant wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100533/ --- (Updated Feb. 3, 2011, 2:09 p.m.) Review request for Plasma. Summary --- Add the option to qalculate to show the result in binary, octal, decimal and hexadecimal at the same time. This only works if the result is an integer Diffs - applets/qalculate/qalculate_settings.h cab44e9 applets/qalculate/qalculate_settings.cpp b317e67 applets/qalculate/qalculate_labels.cpp b04c538 applets/qalculate/qalculate_engine.cpp 708f3b2 applets/qalculate/qalculate_labels.h 4cf31e2 Diff: http://git.reviewboard.kde.org/r/100533/diff Testing --- built and tested the applet Screenshots --- settings http://git.reviewboard.kde.org/r/100533/s/63/ result http://git.reviewboard.kde.org/r/100533/s/64/ Thanks, Jef ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
Hey, On Thursday, February 03, 2011 15:29:38 Ted Gould wrote: On Thu, 2011-02-03 at 14:37 +0100, Marco Martin wrote: On Thursday 03 February 2011, Ted Gould wrote: One of the projects we're doing is to try and make Unity more accessible. To that end we'd like to add properties to add accessible labels for the icons that could be given to screen readers. We're planning on issuing warnings if an icon is set without an accessible label, it would be great if the KDE object could do the same. Here are the properties that we're thinking about: IconAccessibleLabel and AttentionAccessibleLabel. They should be strings describing the icons/movies, localized and change with the icon. An example would be Battery 45%. --Ted PS - I don't think that OverlayAccessibleLabel makes sense, but I'd love to hear people's comments on that. This is a really good idea, let's analyze it. Basically, what the normal icon, the attention icon and the overlay indicate is a status, someting descriptive about what's going on (let's say battery 45%) now, we have a text representation, and that is what's written in the tooltip. this may or may not be enough for a screenreader to represent it textually... Yeah, in talking to the a11y folks they like tooltips, but they really wanted another label as sometimes the tooltips don't describe the icon enough for a blind user to know what it means. Apparently screen readers can distinguish and make tooltips additional information as well. Also, sometimes tooltips can be too complex for screen readers to do a good job with them. On the other hand, it requires application developers to add another string in their code to all UI elements -- something which might be easily forgotten by those that don't care a lot about a11y (I fear that this applies to a lot of developers). Falling back to the tooltip sounds like something sensible for those cases. In any case, we should clearly document why it makes sense (justifies the extra work for developers and translators), so people actually do it. Additionally, some guidelines how to make those accessible labels useful, i.e. not just repeat the tooltip, but making it convey the needed information in a form suitable for screen readers. The overhead of such a thing is non-trivial, but I can't really judge the importance to a11y, so the above are just some thoughts about this proposed property. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Thumbnail buttons and actions
One feature I think would be useful would be if applications were able to add buttons to their thumbnails in the task manager. Use cases could include play and pause buttons on media players, or tab lists on web browsers. I got what I interpreted as positive feedback when I mentioned this earlier, so I thought it warranted a more detailed look. So far I have seen two major proposals about how to implement this: applications can use plasma widgets as their thumbnails, or a dbus-based system similar to (or added to) the system tray spec. I think the former is not a good idea because it is KDE-exclusive, which discouraged use by non-KDE applications. I will use the latter proposal, then. Whether it is a new spec or an extension to an existing spec if beyond my technical knowledge, as is specific implementation details, so I my discussion will unfortunately be somewhat superficial. Nevertheless, I hope it will be helpful for getting some forward movement on this. For this idea, the issue is that there are a lot of ways that these sorts of interfaces could be represented. That is why you will see a lot of hints. These hints are provided by either the application or the task manager (or whatever is displaying the buttons), but the one receiving the hints can choose to ignore them. I also wanted to keep in mind some earlier proposals for a dbus-based system for putting buttons in the title bar. Whether that is a good idea or not, I think that could also be a potential implementation of this spec, which is another reason why the use of hints. However, since the current focus is on task managers, I will refer to that exclusively from now on. You can replace task manager with anything else that might want to display the buttons. The most basic element is a button. Buttons are provided the application, and displayed by the task manager. The button has a number of properties. The application can send properties to existing buttons, which replace the existing property, as well as send orders to add or remove buttons. 1. Icon hint. The icon hint not a picture, it simply an icon name from the freedesktop.org icon naming spec. The icon theme used would be up to the task manager, and the task manager could potentially override certain buttons and replace them with others (I am not sure why it would want to, but since it is just a name this would be possible). This could also be a list of icon names, which would lead to a button that cycles through the icons on each click (such as a play/pause button, but making it an arbitrary-length list is more flexible). 2. Button text hint. How the text is handled is once again up to the task manager. It could be a mouse-over text or displayed permanently somewhere near the button. This could also be a list with the same number of text strings as the icon list. The text can be html formatted, but task managers can choose to ignore the formatting. 3. Button state hint. This is either enabled or disabled. How the button state is indicated by the task manager, if at all, is once again up to it. This would probably be a bool. 4. Button location hint. This is either N, S, E, W, NW, SW, NE, or SE, with N being the north (top) edge, E being the east (right) edge, NE being the north-east (top-right) corner, and so on. The hint tells where the button should be located. Exactly how to interpret the location hint, or whether to ignore it completely, depends on task manager. This would probably be an enum or integer corresponding to each state. 5. Button order hint. This is used to determine the order of the buttons at a given location. The smaller the value (it would be a signed int), the further to the left it would be. So for instance if you could give the back button a value of -10, the play button a value of 0, the next button a value of 10, and put them all at the S location, you would have back, play, then forward (in that order) along the bottom edge. The task manager could re-interpret this (for instance reversing it for right-to-left languages) or ignore it entirely. The reason for using signed ints is to make it easier to add and remove buttons while maintaining a desired ordering. How to handle orders at a corner, for instance, would also be up to the task manager. 6. Button type. I will discuss this below, but I want to point out that the type is a property of the button, since some implementations might want to display different button types differently, and some might not want to display certain button types at all. Buttons types fall into three categories: 1. Action buttons. Basic buttons. They send both click and release signals back to the application. Examples include play and pause buttons. 2. Menu buttons. These popup a menu. They send a request to the application, which provides a list of items for a menu, and then the resulting item is sent back. The menu would probably be based on how it is down for the system tray spec.
Re: the next step on the desktop
On Thu, Feb 3, 2011 at 3:46 AM, Ivan Cukic ivan.cu...@kde.org wrote: Hi all, Sorry, I forgot to write who wrote which quote... 1 On the horizontal application launchers While the horizontal format is fine for a few icon-only launchers (quick launch, docks etc.), the idea to Have it open a horizontal menu that replaces or covers the panel entirely. This menu would show a list of your applications folders, as well as is bad for the following reasons: 1.1. we (RTL and LTR writing humans :) ) are used to read horizontal text sequentially - from the beginning to the end, like a single paragraph, not to separate it in stacks. With vertically separated items, we can easily find the beginning of each one, like multiple paragraphs. (finding the third parahraph in a page is much easier than finding the third sentence) That doesn't seem to be a problem with the add widgets dialog, or with the default Dolphin icons view, either.. I think it is fine if they are clearly separated visually. These aren't big blocks of text, they are clearly separated combinations if cons and text. 1.2. Since the items are horizontal, in order to move the mouse from the first item to the last, you need to travel much more than you need to with vertical lists. That is partly the point, I am trying somewhat to discourage use of the application launcher in favor of favorites and krunner. Most people should very rarely need to use the application launcher. Those who do need to use it a lot can use the kickoff-style one, which will not be removed. The same problem is true for the SL containment, I might add. 1.3 Due to the same reason as 1.2, you can fit less items in a row than in a column (even when the width of a screen is much bigger than its height) That assumes that you use the whole height of the screen for the vertical menu, but do you? Certainly not be default. I think it would end up being pretty similar since this uses the whole horizontal space. 2. On covering the work Like the application launcher, it opens horizontally rather than vertically (so it doesn't cover what you are working on) I actually like the concept behind this, but I fail to see the importance of it. If you want to start a new application, it is going to open in front of your current work anyway, so why shouldn't the launcher? That assumes you only use it for launching applications. This would not be the case. It would be used for krunner, for instance. I have lots of trouble with krunner's calculator and dictionary runners since they often cover what I am trying to calculate or define. It would be used for contacts, for activities, for a wide variety of things that you wouldn't want to cover your work. It may be slightly less convenient for launching applications, but I think it has a lot of benefits for other tasks. If you are solely concerned with issue with lunching applications, you could make it so that clicking one of the application folders brings up a vertical menu that you can then use to navigate that folder. Whether it displays a menu or replace the current horizontal view could be up to the individual thing being displayed, since while I agree some things are better displayed vertically, while others are better displayed horizontally. 3. On the taskbar text I've used smooth tasks applet which hides the text. While it *looks* awesome, it fails when you have multiple windows from the same application (Gimp, Inkscape, OOo etc.) - you need to hover the items, to get the text and the window thumbnail in order to activate one of them. This is a problem with any grouped task manager. The default task manager has the same problem when grouping is enabled (which it is by default). In an earlier email I explained this in the benefits and drawbacks of dock-style task manager. 4. On 'verticalness' of it all :) In any kind of Vertical launch menu (Windows* kde3, Kickoff, Lancelot) you have a longer number of step to do before you find whatever you want This has nothing to do with something being vertical, or horizontal. It is about 'popup' launchers. As you can see here: http://imagebin.org/135938 you can have a vertical (with autohide for example) panel launcher that is as accessible as a dock True, which is why I am proposing putting more focus on favorite applications and krunner, putting both of those right in the panel. I think accessing those without having to bring up the application launcher would be much faster. -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
On the other hand, it requires application developers to add another string in their code to all UI elements -- something which might be easily forgotten by those that don't care a lot about a11y (I fear that this applies to a lot of developers). Falling back to the tooltip sounds like something sensible for those cases. There are ways to strongly suggest application developers to define such strings: for example outputing warnings on stderr when a KSNI goes live without having proper a11y properties set. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add option to qalculate to show the result in different bases at the same time
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100533/ --- (Updated Feb. 3, 2011, 3:58 p.m.) Review request for Plasma. Changes --- Updated the diff after Matteos comments Summary --- Add the option to qalculate to show the result in binary, octal, decimal and hexadecimal at the same time. This only works if the result is an integer Diffs (updated) - applets/qalculate/qalculate_engine.cpp 708f3b2 applets/qalculate/qalculate_labels.h 4cf31e2 applets/qalculate/qalculate_labels.cpp b04c538 applets/qalculate/qalculate_settings.h cab44e9 applets/qalculate/qalculate_settings.cpp b317e67 Diff: http://git.reviewboard.kde.org/r/100533/diff Testing --- built and tested the applet Screenshots --- settings http://git.reviewboard.kde.org/r/100533/s/63/ result http://git.reviewboard.kde.org/r/100533/s/64/ Thanks, Jef ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add option to qalculate to show the result in different bases at the same time
On Feb. 3, 2011, 3:15 p.m., Matteo Agostinelli wrote: applets/qalculate/qalculate_labels.h, lines 32-56 http://git.reviewboard.kde.org/r/100533/diff/1/?file=8207#file8207line32 I don't understand why you created the AppletSettings class. Wouldn't it be easier to simply pass a pointer to QalculateSettings in the constructor? This would save some code duplication. Or am I missing something? I did not want to drag the whole QalculateSettings around, but it is probably a better idea anyway. I'll update the code first. - Jef --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100533/#review1178 --- On Feb. 3, 2011, 3:58 p.m., Jef Steelant wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100533/ --- (Updated Feb. 3, 2011, 3:58 p.m.) Review request for Plasma. Summary --- Add the option to qalculate to show the result in binary, octal, decimal and hexadecimal at the same time. This only works if the result is an integer Diffs - applets/qalculate/qalculate_engine.cpp 708f3b2 applets/qalculate/qalculate_labels.h 4cf31e2 applets/qalculate/qalculate_labels.cpp b04c538 applets/qalculate/qalculate_settings.h cab44e9 applets/qalculate/qalculate_settings.cpp b317e67 Diff: http://git.reviewboard.kde.org/r/100533/diff Testing --- built and tested the applet Screenshots --- settings http://git.reviewboard.kde.org/r/100533/s/63/ result http://git.reviewboard.kde.org/r/100533/s/64/ Thanks, Jef ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
On Wednesday, February 2, 2011, Alex Fiestas wrote: On 02/02/2011 09:57 PM, Aaron J. Seigo wrote: --- About taskmanager: (1) use only icons (this already happens when taskbar is full): - icon size on the panel should be shortcut size (launcher size, =Kickoff) i'm not interested in making it a clone of windows7 :) I'm not interested neither, but we have to find a way to improve the current paradigm, not sure how but we have to do it. I'm not going to talk about usability because I don't know anything on the subject but I can see a couple of points that are according to the experiences I had I think they are as true as the snow is white :p 1-Vertical launch menu is way more complex than the dock concept. In any kind of Vertical launch menu (Windows* kde3, Kickoff, Lancelot) you have a longer number of step to do before you find whatever you want to find, or whatever you want to launch. For example right now if I want to execute KGet I have to: Click Icon--Application-Internet-Scroll down (yes, this is another step), Click on KGet. this is a bogus argument for docks. why? because you are comparing two completely different things: finding versus launching. what you're suggesting is an external application browser with only mandatory launchers on the panel. what we have now is optional launchers on the panel with a built in application browser. perhaps the missing piece is maing it easy enough to go from the application browser to having launchers on your panel. in any case, with your dock+external app browser, to launch kget i'd have to open dolphin to applications - internet - scroll - click. maybe if i'm lucky i don't scroll because it's big enough. the interface is also more complex though, so subtract a few of those points back. it's not a win. it's shuffling stuff about. so perhaps we could start this discussion from a comletely different angle and instead of trying to show that docks are better than browser based app launchers, since in my mind they actually do two very different things and are similarly clumsy for launching apps that aren't already part of your launcher set, let's start with first principles: * what does the user need to be able to do, in descending order along two axis of frequency and required speed * how can we meet each of those needs docks are an easy answer because they are different from what we have and are a trend (i'd even call them a fad) right now. they are visually simpler if not actually simpler to use. they have their own problems as well, not that we ever talk about those because docks are Cool(tm). so let's not start by crafting a dock. if we end up at a dock, great. but let's do so from first principles. i'd also suggest that we shouldn't let ourselves get pinned down into the idea of one panel at the top or the bottom that spans the entire screen. we should allow our imagination to use all parts of the whole screen, the dashboard, multiple panels, etc. it's a longer, harder route but we may come up with something actually innovative versus following someone yet again for not good reason than to follow someone. Also, the typically this vertical menus doesn't invite you naturally to create a set of Favorite applications since these menus are typically hidden all the time launchers on the panel are useful, yes. (I don't know anybody that makes a good use of Kickoff Favorite... do you?) you're going to have me: but yes i do. and it isn't me, either :) i don't use kickoff, but i know a few people who use the favorites there. 2-Taskbar clutters A LOT the panel, and label invites you to read. In the last discussion about taskbar Icons only one of the arguments by Aaron was: Labels add useful information, and I agree but to get that information you have to read, and no matter how fast you can do it image recognition is always faster once you know the relationship between Image--meaning. and which one of the two firefox buttons on my panel is the downloads? ah, right, we will group them, then make people click on them and manage them via the window manager. i don't see the benefit. as for image recognition being faster ... we already do have images. our choicse isn't images or text, it's images only or images and text -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday 03 February 2011 16:51:34 todd rme wrote: or tab lists on web browsers. Just as a note: I'm working on that together with rekonq developers (see complete thread [1]). I expect to start the kwin side of the implementation after shadow rework. Cheers Martin [1]: http://mail.kde.org/pipermail/rekonq/2011-January/002316.html signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
On Wednesday, February 2, 2011, todd rme wrote: what would be helpful is to do a mockup of your ideas below, and keep evolving it as we continue the discussion. 1. Get rid of favorites from the application launcher. Focus on making runners easy, intuitive, and clear. These go in the middle. don't favourites and krunner do rather different things? 2. Get rid of applications from the system tray. Integrate those with the task manager (including buttons-on-thumbnails). System tray goes on the right. agreed; this is a great little project for someone who'd like to go down that route. 3. Notifications go to the right of the system tray. This is for symmetry. Expander for hidden items (which should probably never exist in the first place now) should go on the left. we found this doesn't work as well because notifications is aways there while the other items may come and go, which means movement. so the more stable things being towards the middle tends to be better. and yes, that means that the system tray should probaby swap order depending on where in a containment it is :) 5. To the right of the application launcher, have a text entry field. This is krunner. Like the application launcher, it opens horizontally yes, i'd like to see a plasmoid version of krunner. since the results area is already a bunch of QGraphicsWidgets, this should be quite doable. would you like to give this a try? Krunner entries also have stars to place them as launchers. Other runners can determine their own use for the stars, or turn them off. For instance the star in the plasma applet runner would add the applet to your panel. this could probably already be prototyped with the existing krunner. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
A.S. I might sound like I'm totally against the ideas proposed, I'm not - I'm just pointing out the potential problems instead of just +1-ing the good parts. That doesn't seem to be a problem with the add widgets dialog, or with the default Dolphin icons view, either.. I think it is fine if they are clearly separated visually. These aren't big blocks of text, they are clearly separated combinations if cons and text. Lets entertain the idea that it doesn't (although I'm not lenient to agree on that one :) ) - you suggested to show it in the panel itself. By default, panel's height is not enough to fit in the 'icon above text' items, you you'd need to end up with a format like the current taskbar. That assumes that you use the whole height of the screen for the vertical menu, but do you? Certainly not be default. I think it Well, you can. If you use the classic menu, it stretches as much as it needs. Shelf applet as well (though it can't really be used for general app launching yet) That assumes you only use it for launching applications. This would not be the case. It would be used for krunner, for instance. I have lots of trouble with krunner's calculator and dictionary runners since Ok, again, when you do the calculations, krunner takes 200x50 pixels (approx) - is it much? (I'm not saying that replacing panel contents is bad, just that it has some bad side-effects) If you are solely concerned with issue with lunching applications, you could make it so that clicking one of the application folders brings up a vertical menu that you can then use to navigate that folder. Whether it displays a menu or replace the current horizontal view could be up to the individual thing being displayed, since while I agree some things are better displayed vertically, while others are better displayed horizontally. The idea is intriguing. I have my doubts when reading about it, but it may prove to be perfect while using it. (if it becomes real) This is something that could go very nicely with the global menu bar (ala MacOS) - the horizontal menu you are proposing is essentially that, but for the 'workspace' and not for the app itself. This is a problem with any grouped task manager. The default task manager has the same problem when grouping is enabled (which it is by default). In an earlier email I explained this in the benefits and drawbacks of dock-style task manager. Agreed (as with your pros and cons of docks). I just don't find the 'current default has problems' to be a reason for 'it is not important whether a new idea has the same problem) True, which is why I am proposing putting more focus on favorite applications and krunner, putting both of those right in the panel. I think accessing those without having to bring up the application launcher would be much faster. I agree, but that part is possible with the current system as well. Just for that, we'd only need a krunner plasmoid (IIRC, it exists, just don't know where :) ) Ivan -- I don't really trust a sane person. -- Lyle Alzado ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: (Not|Only)ShowIn (2/3)
On Wednesday, February 2, 2011, Ted Gould wrote: We also started to use some of the application indicators from applications in the launcher on the left side of the screen. We use the application indicator to provide additional menus for the launcher which we call a quick list. We're currently choosing which application is on the panel and which is in the launcher based on heuristics, but we'd like to have a way for applications to explicitly control that behavior if they so desire. don't we have a way to do this already with the Categories? applications - go into the launcher. not applications - go into the panel / system tray. do you have use cases (i'm assuming you must :) for where that dichotomy does not hold up? What we'd like to add is two properties that are lists of strings: NotShowIn and OnlyShowIn. These would work exactly the same as the same properties in Desktop files where an application could say NotShowIn=[Unity Launcher] and ensure that they'd never end up with that item used as a quicklist. this makes for a great hack to customize apps for a specific shell. unfortunately for the app developer (and their users) when that shell is replaced, then things go to hell all over again. in the .desktop files, this is used to pair platform specific apps to their specific platforms. this mechanism you describe is sort of the opposite: pair apps to various platforms in different ways. the .desktop approach works due to the symmetry. i expect the status notifier approach to fail due to lack of that same kind of symmetry. in the example of Unity, it only will work if the app developers release their apps along with Unity. otherwise, Unity can never change its design strategy without breaking 3rd party entries. perhaps you're approaching this from a apps we write / patch angle, but eperience shows that such patterns break because 3rd party devs do exist, they don't follow shell development very well, have their own ideas of what's good and what isn't and users flock to them all the same. it's what gave us the mess in the system tray in the first place :) so instead of the application prescribing what to do, which requires all sorts of knowlege on the part of the app developer (what the right thing to do is in each shell, what the different shells even are), we should define the use cases and come up with a way for the app devel to add appropriate metadata to their icon that can be used by _any_ shell to make the right decisions, whatever that means for them over time. without the use cases you have in mind, it's really hard for me to offer anything more specific, but perhaps you could? Most applications would hopefully not find a reason to use this, but for those that would like the precise control it would be available. to me, this is a great reason not to do this :) application developers have demonstrated after 15 or so years of system tray usage that they are not able to manage these things well on their own. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
first, thanks for working with us on this Ted. it really helps keep things moving forward in a coordinate fashion, and makes our lives (and hopefully yours) a lot brighter. :) oh, and you don't need to CC Marco and I, we're on the plasma-devel list :) On Wednesday, February 2, 2011, Ted Gould wrote: One of the projects we're doing is to try and make Unity more accessible. To that end we'd like to add properties to add accessible labels for the icons that could be given to screen readers. We're planning on issuing warnings if an icon is set without an accessible label, it would be great if the KDE object could do the same. Here are the properties that we're thinking about: IconAccessibleLabel and AttentionAccessibleLabel. They should be strings describing the icons/movies, localized and change with the icon. An example would be Battery 45%. when would the AttentionAccessibleLabel be used (as opposed to the Icon one)? are they ever used simultaneously? is the Icon label a more-or-less static description fo the icon, and the Attention label is more information for when something exciting happens? can we re-purpose the tooltip for this? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
1. Get rid of favorites from the application launcher. Focus on making runners easy, intuitive, and clear. These go in the middle. don't favourites and krunner do rather different things? They do, but when you use krunner, that means you don't have the thing you want in favs. (this one proved to be correct for L's users) 5. To the right of the application launcher, have a text entry field. This is krunner. Like the application launcher, it opens horizontally yes, i'd like to see a plasmoid version of krunner. since the results area is already a bunch of QGraphicsWidgets, this should be quite doable. would you like to give this a try? I have definitely seen this applet before :) Maybe it is in the playground @OP: The technical issue with krunner as an applet is plasma-desktop crashing. That is the reason Kickoff and Shelf applet have limited number of runners enabled for searching. Cheerio -- I don't really trust a sane person. -- Lyle Alzado ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Desktop Key (3/3)
On Wednesday, February 2, 2011, Ted Gould wrote: We'd like to suggest an additional key for .desktop files that lists the IDs of Status Notifier Items that an application exports. This will allow us to better match SNI items when we are using them as quicklists, as errors are very embarrassing ;) For this key we're suggesting: X-KDE-StatusNotifierItems which would be a list of strings. this sounds useful indeed for the use cases you outlined. +1 from me. (and doc the work i went through considering this one: something i pondered was a slightly more complex way of doing this might be to have the SNI carry with it the default menuid (usually something like kde- kcalc.desktop) and then those menuids could be mapped to launchers, quicklists, etc as the system sees fit. it is more complex, however, and would require SNIs to actually have a menuid available to use, which not all do (or should). alternately, an SNI could include the list of .destop files it matches, but there's obviously not going to be enough knowledge at runtime in all SNIs of the underlying system to know what best to do. so, while i considered these, i dropped them on the floor as unworkable. back to the proposal as the most elegant and useful :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
On Thu, Feb 3, 2011 at 11:54 AM, Aaron J. Seigo ase...@kde.org wrote: On Wednesday, February 2, 2011, todd rme wrote: what would be helpful is to do a mockup of your ideas below, and keep evolving it as we continue the discussion. 1. Get rid of favorites from the application launcher. Focus on making runners easy, intuitive, and clear. These go in the middle. don't favourites and krunner do rather different things? Typo, sorry. I meant launchers. 3. Notifications go to the right of the system tray. This is for symmetry. Expander for hidden items (which should probably never exist in the first place now) should go on the left. we found this doesn't work as well because notifications is aways there while the other items may come and go, which means movement. so the more stable things being towards the middle tends to be better. and yes, that means that the system tray should probaby swap order depending on where in a containment it is :) Ah yes, you pointing this out before but I forgot about it. It isn't a critical part, except in this case I would put the clock to the left so it is still next to the notification area. 5. To the right of the application launcher, have a text entry field. This is krunner. Like the application launcher, it opens horizontally yes, i'd like to see a plasmoid version of krunner. since the results area is already a bunch of QGraphicsWidgets, this should be quite doable. would you like to give this a try? I probably won't have time to work on anything related to this until at least after 4.7 is out, I'm afraid, due to moving and changing jobs. The important bit was the horizontal launcher and krunner. What do you think of those? -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
On Thursday, February 3, 2011, Aurélien Gâteau wrote: There are ways to strongly suggest application developers to define such strings: for example outputing warnings on stderr when a KSNI goes live without having proper a11y properties set. catching and punishing sins (though a warning is hardly a punishment unless we email the devs every time it happens .. yes, i'm joking ;) is not a good approach compared to being able to prevent the sins in the first place. developers have every motivation to add tooltips and they usually do. it's also easily tested by them: hover the entry with their mouse. if we use that same data for a11y, we prevent the sins. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
On Thursday, February 3, 2011, Sebastian Kügler wrote: On the other hand, it requires application developers to add another string in their code to all UI elements -- something which might be easily forgotten by those that don't care a lot about a11y (I fear that this applies to a lot of developers). Falling back to the tooltip sounds like something sensible for those cases. the tooltip really ought to be the textul representation of the entry in the first place. another benefit of re-using the tooltip is that it's easy for any developer (or user) to test: hover the entry with the mouse. a11y labels are going to be a lot harder for the average dev to test (well, plasmaengineexplorer makes it easy enough, but that's still a sort of backwoods for most developers) In any case, we should clearly document why it makes sense (justifies the extra work for developers and translators), so people actually do it. Additionally, some guidelines how to make those accessible labels useful, i.e. not just repeat the tooltip, but making it convey the needed information in a form suitable for screen readers. +1 -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday, February 3, 2011, Martin Gräßlin wrote: On Thursday 03 February 2011 16:51:34 todd rme wrote: or tab lists on web browsers. Just as a note: I'm working on that together with rekonq developers (see complete thread [1]). I expect to start the kwin side of the implementation after shadow rework. apps being able to expose tabs in windows would be great. +1 to that. (as for apps, i still wish we had a completed silky; sebas: we should do some project dev and promo around it and see if we can't get some new developers plonking away on it!) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday, February 3, 2011, todd rme wrote: One feature I think would be useful would be if applications were able to add buttons to their thumbnails in the task manager. Use cases could this be done with the status notifier spec? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
On Thu, Feb 3, 2011 at 12:16 PM, Ivan Cukic ivan.cu...@kde.org wrote: A.S. I might sound like I'm totally against the ideas proposed, I'm not - I'm just pointing out the potential problems instead of just +1-ing the good parts. That doesn't seem to be a problem with the add widgets dialog, or with the default Dolphin icons view, either.. I think it is fine if they are clearly separated visually. These aren't big blocks of text, they are clearly separated combinations if cons and text. Lets entertain the idea that it doesn't (although I'm not lenient to agree on that one :) ) - you suggested to show it in the panel itself. By default, panel's height is not enough to fit in the 'icon above text' items, you you'd need to end up with a format like the current taskbar. Right, which is why I said replaces or covers the panel, rather than just replaces. If the panel is big enough, it would replace the panel, but if it isn't you would need something bigger that would cover it. That assumes that you use the whole height of the screen for the vertical menu, but do you? Certainly not be default. I think it Well, you can. If you use the classic menu, it stretches as much as it needs. Shelf applet as well (though it can't really be used for general app launching yet) Right, but by default the default application launcher does not do this. This is meant as a default layout optimal for most basic users. A user who knows enough to resize the application launcher or switch to a different one would also know enough to change out my proposal for one of the existing menus. That assumes you only use it for launching applications. This would not be the case. It would be used for krunner, for instance. I have lots of trouble with krunner's calculator and dictionary runners since Ok, again, when you do the calculations, krunner takes 200x50 pixels (approx) - is it much? (I'm not saying that replacing panel contents is bad, just that it has some bad side-effects) Those are only examples. For the activities runner this will be an even bigger issue. If you are solely concerned with issue with lunching applications, you could make it so that clicking one of the application folders brings up a vertical menu that you can then use to navigate that folder. Whether it displays a menu or replace the current horizontal view could be up to the individual thing being displayed, since while I agree some things are better displayed vertically, while others are better displayed horizontally. The idea is intriguing. I have my doubts when reading about it, but it may prove to be perfect while using it. (if it becomes real) This is something that could go very nicely with the global menu bar (ala MacOS) - the horizontal menu you are proposing is essentially that, but for the 'workspace' and not for the app itself. I guess somewhat. This is a problem with any grouped task manager. The default task manager has the same problem when grouping is enabled (which it is by default). In an earlier email I explained this in the benefits and drawbacks of dock-style task manager. Agreed (as with your pros and cons of docks). I just don't find the 'current default has problems' to be a reason for 'it is not important whether a new idea has the same problem) My point was a comparison between the existing default and a new proposed default. This is not a drawback from this perspective since it is the same. I agree this is a drawback, but I think it is more compensated for by the benefits I listed. If there was a way to make it work in all situation I would be all for it, but I have not seen and have not been able to come up with a solution that has all the benefits of the existing interfaces. True, which is why I am proposing putting more focus on favorite applications and krunner, putting both of those right in the panel. I think accessing those without having to bring up the application launcher would be much faster. I agree, but that part is possible with the current system as well. Just for that, we'd only need a krunner plasmoid (IIRC, it exists, just don't know where :) ) We would need a krunner plasmoid, and a better interface for assigning launchers to the task manager, and I think a better way of displaying launchers, and I think it needs changes to the application launcher as well (such as removing favorites, and putting more focus on finding applications you don't use often). I am not proposing just changes to the interface, the focus is on a change to the work-flow, with changes to the interface chosen to encourage and support this work-flow. -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thu, Feb 3, 2011 at 12:47 PM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, February 3, 2011, todd rme wrote: One feature I think would be useful would be if applications were able to add buttons to their thumbnails in the task manager. Use cases could this be done with the status notifier spec? I don't know. As I said, I don't have any technical knowledge of that spec. That is why I said this could use this spec, or be an extension to it, or be an entirely new spec. I don't know enough to know the relative merits of any of these approaches to recommend one over the others. -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday 03 February 2011 18:47:01 Aaron J. Seigo wrote: On Thursday, February 3, 2011, Martin Gräßlin wrote: On Thursday 03 February 2011 16:51:34 todd rme wrote: or tab lists on web browsers. Just as a note: I'm working on that together with rekonq developers (see complete thread [1]). I expect to start the kwin side of the implementation after shadow rework. apps being able to expose tabs in windows would be great. +1 to that. (as for apps, i still wish we had a completed silky; sebas: we should do some project dev and promo around it and see if we can't get some new developers plonking away on it!) +100 to that. I would rather like to see an awesome selkie and a proper solution to the web problem, than sticking to the broken one app as container for many app concept. So exposing the tabs is for me just a short term solution on the road to silk. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
On Thursday, February 3, 2011, Ivan Cukic wrote: 1. Get rid of favorites from the application launcher. Focus on making runners easy, intuitive, and clear. These go in the middle. don't favourites and krunner do rather different things? They do, but when you use krunner, that means you don't have the thing you want in favs. (this one proved to be correct for L's users) the suggestion is then to put favorites and runners in physical locality to each other? 5. To the right of the application launcher, have a text entry field. This is krunner. Like the application launcher, it opens horizontally yes, i'd like to see a plasmoid version of krunner. since the results area is already a bunch of QGraphicsWidgets, this should be quite doable. would you like to give this a try? I have definitely seen this applet before :) Maybe it is in the playground hm.. i see something in playground/base/plasma/applets/runnapplet will have to check it out. @OP: The technical issue with krunner as an applet is plasma-desktop crashing. That is the reason Kickoff and Shelf applet have limited number of runners enabled for searching. insert obvious response here :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday 03 February 2011, Aaron J. Seigo wrote: On Thursday, February 3, 2011, todd rme wrote: One feature I think would be useful would be if applications were able to add buttons to their thumbnails in the task manager. Use cases could this be done with the status notifier spec? sounds to me like a set of action associated to an item... so yes ;) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thu, Feb 3, 2011 at 1:04 PM, Marco Martin notm...@gmail.com wrote: On Thursday 03 February 2011, Aaron J. Seigo wrote: On Thursday, February 3, 2011, todd rme wrote: One feature I think would be useful would be if applications were able to add buttons to their thumbnails in the task manager. Use cases could this be done with the status notifier spec? sounds to me like a set of action associated to an item... so yes ;) Cheers, Marco Martin Does the spec have hints for locations, the ability to pass sets of significant-sized pixmaps with the ability to click on them, categories the tool displaying them can use as cues, and the other parts necessary to display, organize, and format the buttons around the edge of a 2D block? -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday, February 3, 2011, todd rme wrote: On Thu, Feb 3, 2011 at 1:04 PM, Marco Martin notm...@gmail.com wrote: On Thursday 03 February 2011, Aaron J. Seigo wrote: On Thursday, February 3, 2011, todd rme wrote: One feature I think would be useful would be if applications were able to add buttons to their thumbnails in the task manager. Use cases could this be done with the status notifier spec? sounds to me like a set of action associated to an item... so yes ;) Cheers, Marco Martin Does the spec have hints for locations, the ability to pass sets of significant-sized pixmaps with the ability to click on them, categories the tool displaying them can use as cues, and the other parts necessary to display, organize, and format the buttons around the edge of a 2D block? answer: you don't want application developers doing that. it assumes a 2D block. what happens when we change that? it assumes app devs know where to position things: they don't. :) on the app side always set metadata, enough so the rendering app can decide how to sort it out. on the visualization side, do the arranging. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Desktop Key (3/3)
On Thursday, February 3, 2011, Ted Gould wrote: On Thu, 2011-02-03 at 14:45 +0100, Marco Martin wrote: could still be a bit error prone, but i can't think of more automatic ways. it could also be done on the other way around, by having a list of desktop file paths as a property of the notifier item, but wouldn't be better I think... Yeah, it's not impossible to have errors. We hope that distro's would be able to police that some though (and distro patch appropriately). Perhaps a naming guide would be appropriate so there is less conflict? yes, this could (should?) be added to the SNI specification WRT the desktop file being a property I like that too. The only caveat is that with libindicate we did that, and we've gotten a surprising amount of push back from developers. I'm really unclear on why, but they don't like having the path to the desktop file in their code. I honestly think they're being irrational, but just to let you know there is some concern there. aha; good to know .. always a balancing act between shell, lib and app devs ;) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thu, Feb 3, 2011 at 1:25 PM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, February 3, 2011, todd rme wrote: On Thu, Feb 3, 2011 at 1:04 PM, Marco Martin notm...@gmail.com wrote: On Thursday 03 February 2011, Aaron J. Seigo wrote: On Thursday, February 3, 2011, todd rme wrote: One feature I think would be useful would be if applications were able to add buttons to their thumbnails in the task manager. Use cases could this be done with the status notifier spec? sounds to me like a set of action associated to an item... so yes ;) Cheers, Marco Martin Does the spec have hints for locations, the ability to pass sets of significant-sized pixmaps with the ability to click on them, categories the tool displaying them can use as cues, and the other parts necessary to display, organize, and format the buttons around the edge of a 2D block? answer: you don't want application developers doing that. it assumes a 2D block. what happens when we change that? it assumes app devs know where to position things: they don't. :) on the app side always set metadata, enough so the rendering app can decide how to sort it out. on the visualization side, do the arranging. But how does the visualization know how to arrange things? Also, there is the issue with passing pixmaps. -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: (Not|Only)ShowIn (2/3)
On Thursday, February 3, 2011, Ted Gould wrote: The use case was use cases! excellent ... :) people wanting different menus on the panel vs. on the launcher. crazy idea: different menus from the same SNI for different (well-defined in the spec) contexts? if the SNI only provides a generic menu, use that everywhere. if they provide a launcher menu, use that for launchers? we'd need a set of menu contexts (generic or primary controller, launcher, ..?) Or not appearing on the panel at all even if there wasn't a launcher available. could be a piece of metadata in the SNI itself to dictate this. (and then it would work with any launcher.) So the specific case was with Tomboy where in the menu on the panel they wanted to have a Quit button but the launcher menu automatically has a close (through the WM) and they didn't want both. sounds like we need/want action-level metadata. Also, in our specific case there are more restrictions on the menus in the launcher (no submenus) so if an app wanted to use those they wouldn't want it to appear in the launcher. this can be determined with a heuristic? I would imagine that for most applications if they were going to use this feature they would be building more than one Item. They'd build one for a very specific visual target and then another that is a generic item for all other visualizations. assuming they know of the available visualizations (and their design guidelines), also create a generic one and then actually get the visualization-specific ones right (esp over time - what happens when the visualization changes design in some way?). it's a lot of overhead for the developer and very prone to breakage over time. any time we've put visualization control in app developer hands things get messy very quickly over the years due to these issues :( for Canonical, you have Unity today but in 5 years what will you have? maye something different. it's probably better not to get a whole bunch of app code specific to today's Unity design that in N years you're going to have to either provide legacy support for (probably with hacks) or which will result in having to re-work all those apps .. again. for KDE, it's even trickier: we don't have just one to-market product to support. different vendors ship Plasma in different forms and configurations, so we have to deal with instant legacy whenever these kinds of features are introduced. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
On Thursday, February 3, 2011, Ted Gould wrote: On Thu, 2011-02-03 at 14:37 +0100, Marco Martin wrote: On Thursday 03 February 2011, Ted Gould wrote: One of the projects we're doing is to try and make Unity more accessible. To that end we'd like to add properties to add accessible labels for the icons that could be given to screen readers. We're planning on issuing warnings if an icon is set without an accessible label, it would be great if the KDE object could do the same. Here are the properties that we're thinking about: IconAccessibleLabel and AttentionAccessibleLabel. They should be strings describing the icons/movies, localized and change with the icon. An example would be Battery 45%. --Ted PS - I don't think that OverlayAccessibleLabel makes sense, but I'd love to hear people's comments on that. This is a really good idea, let's analyze it. Basically, what the normal icon, the attention icon and the overlay indicate is a status, someting descriptive about what's going on (let's say battery 45%) now, we have a text representation, and that is what's written in the tooltip. this may or may not be enough for a screenreader to represent it textually... Yeah, in talking to the a11y folks they like tooltips, but they really wanted another label as sometimes the tooltips don't describe the icon enough for a blind user to know what it means. this is true for traditional tooltips, but the ones in a SNI are not like those tooltips at all: they have titles, subtext, etc. they are supposed to, in an SNI, be fully descriptive. are the a11y folks aware of those differences between SNI tooltips and normal ones on e.g. pushbuttons? what this denotes to me is that maybe we need to revamp the documentation around tooltips (and as marco pointed out on irc earlier today, perhaps that was an unfortunate name to choose in the spec :/ ) so that this is very clear to app devs too. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday, February 3, 2011, todd rme wrote: But how does the visualization know how to arrange things? metadata. if there isn't enough metadata or the right sort, we add it. Also, there is the issue with passing pixmaps. this is already available in the spec :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
On 03-02-2011 at 19:05:56 Ivan Cukic ivan.cu...@kde.org wrote: BTW, on of the free DEs (forgot which one) had the standard win-like taskbar, and on Alt+Space (I encountered it by accident) it would replace the taskbar with a 'run' text field. I liked it, but it was no krunner - simple shell exec. This is IceWM, very useful feature when you have very limited resources. ;-) -- Best regards, Michal ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
On 03-02-2011 at 18:57:41 Aaron J. Seigo ase...@kde.org wrote: hm.. i see something in playground/base/plasma/applets/runnapplet will have to check it out. I guess you mean runcommand, there is no directory runnapplet there (at least on SVN). It uses own dialog for results and maybe some other things that should be rewritten. -- Best regards, Michal ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday 03 February 2011, Martin Gräßlin wrote: On Thursday 03 February 2011 18:47:01 Aaron J. Seigo wrote: On Thursday, February 3, 2011, Martin Gräßlin wrote: On Thursday 03 February 2011 16:51:34 todd rme wrote: or tab lists on web browsers. Just as a note: I'm working on that together with rekonq developers (see complete thread [1]). I expect to start the kwin side of the implementation after shadow rework. apps being able to expose tabs in windows would be great. +1 to that. (as for apps, i still wish we had a completed silky; sebas: we should do some project dev and promo around it and see if we can't get some new developers plonking away on it!) +100 to that. I would rather like to see an awesome selkie and a proper solution to the web problem, than sticking to the broken one app as container for many app concept. So exposing the tabs is for me just a short term solution on the road to silk. if marketed well, it could attract quite some people. i envision a selkie done quite like: * the web widget using just the main site web page as now * web apps distributed in packages, with configs, icons for the services, javascript/css snippets to unscrew the site itsef, hiding parts, whatever... * extra toolbars ..and this more or less is present in selkie in it current for, i think? there is where the neat comes. as Nuno briefly mentioned, the other day we were having a nice chat about how the look and stilyng of our current destop applications is not enough(tm) anymore, but to be technically possible to move to a better thing a quite long roadmap is needed. in the selkie package, distribute also qml plasmoids (with eventual services/dataengines, all in js) and will a) nice a set of desktop plasmoids related to that service, but... b) those plamoids can provide ui for selkie itself, as we are doing our device specific profiles for qml plasmoids, there could be a profile for selkie too, so for instance the application could give also tabs with a qml based ui for the service but in a bigger window, so would become alsmost a full application (maybe styled in a semi natie widget style) using the native html ui, will become just the last resort (in another tab?) when a better ui isn't available. * this would look sexy * would show explicitly a way out of the browser * would mark a prototype on how a full desktop application could look without painting limitations qwidgets now have * enough? ;) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
Well seems that despite of the differences in our thoughts, there are a couple of points that everybody agrees on: 1-Maximize the usage of Favorites 2-Maximize the usage of KRunner 3-Find new ways of showing Favorites. Going beyond that in the mailist will be difficult, maybe an irc session could help, but Tokamak seems like the right place and moment to discuss this stuff. What do you think about making a call for mockups and ideas so we can collect ideas and discuss them in the next Tokamak? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
This is IceWM, very useful feature when you have very limited resources. ;-) Strangely enough, I use it from time to time, but completely forgot it was from there :) --- Well, we definitely need mocks of everything, this idea, and everything else people can devise. Maybe we should ask the community to contribute? To make concept-UIs so that we could pull some ideas from there? -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
On Thu, Feb 3, 2011 at 2:28 PM, Ivan Čukić ivan.cu...@kde.org wrote: This is IceWM, very useful feature when you have very limited resources. ;-) Strangely enough, I use it from time to time, but completely forgot it was from there :) --- Well, we definitely need mocks of everything, this idea, and everything else people can devise. Maybe we should ask the community to contribute? To make concept-UIs so that we could pull some ideas from there? There has been a lot of ideas posted to the brainstorm forum about this sort of thing. I think it would be highly worthwhile looking through it. It seems to be a highly under-utilized source of new concepts and ideas, unfortunately. I agree posting requests to the users is good, but I would not neglect the resources already available. -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday, February 3, 2011, Marco Martin wrote: * this would look sexy * would show explicitly a way out of the browser * would mark a prototype on how a full desktop application could look without painting limitations qwidgets now have * enough? ;) this would be truly awesome; merging QML plasmoids and seklie is brilliant. should we add this to our 2011 roadmap? if so, target 4.7 or 4.8? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Thumbnail buttons and actions
On Thursday 03 February 2011, Aaron J. Seigo wrote: On Thursday, February 3, 2011, Marco Martin wrote: * this would look sexy * would show explicitly a way out of the browser * would mark a prototype on how a full desktop application could look without painting limitations qwidgets now have * enough? ;) this would be truly awesome; merging QML plasmoids and seklie is brilliant. should we add this to our 2011 roadmap? sure thing, just did. if so, target 4.7 or 4.8? depends on the work force that can be found, and if selkie wants to have a release for 4.7 i would go for a proof of concept in time for 4.7 ( basic support in the application *seems* quite easy?) full usable thing, at least for a single site for 4.8 Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add option to qalculate to show the result in different bases at the same time
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100533/#review1184 --- Ship it! Great! Please commit/merge. Thanks! - Matteo On Feb. 3, 2011, 3:58 p.m., Jef Steelant wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100533/ --- (Updated Feb. 3, 2011, 3:58 p.m.) Review request for Plasma. Summary --- Add the option to qalculate to show the result in binary, octal, decimal and hexadecimal at the same time. This only works if the result is an integer Diffs - applets/qalculate/qalculate_engine.cpp 708f3b2 applets/qalculate/qalculate_labels.h 4cf31e2 applets/qalculate/qalculate_labels.cpp b04c538 applets/qalculate/qalculate_settings.h cab44e9 applets/qalculate/qalculate_settings.cpp b317e67 Diff: http://git.reviewboard.kde.org/r/100533/diff Testing --- built and tested the applet Screenshots --- settings http://git.reviewboard.kde.org/r/100533/s/63/ result http://git.reviewboard.kde.org/r/100533/s/64/ Thanks, Jef ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
the next step on the desktop : what now?
Hi all, so, we had an astonishing inflow of ideas, opinions and use cases during these days, this was really great, keep em coming! It's amazing how much passion and energy there still is in this particular topic, as the thread says, the next step on the desktop. As ideas flows, there is an important reminder for everyone : remember to put them in the wiki http://community.kde.org/Plasma/2011 or we can get lost pretty quickly ;) Now, all of this is beautiful, but what next, some of those ideas are really good, some less desiderable for various reason, some not really feasible (yet? ;) I would ask people to describe their ideas better with mockups if they can, doesn't matter the quality, don't be afraid if they aren't nuno-grade ;) with them is more easy to explain ideas (or even retract them if doesn't seem to make sense in graphics ;) (btw, Alex just mentioned a neat little app whose main target is apparently exaclty doing mockups easily http://pencil.evolus.vn/en-US/Home.aspx) Next step, will be, do you really want this particular feature? do you have some pain point in particular? that is the best excuse you can have ever to enter in development , try to understand sources, make patches :) but this is for the next time... think about the next step of the desktop people, think about... :D Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
On Thursday 03 February 2011, alex.tolar wrote: Good night everybody, Yo, good evening. thanks for the feedback I really think you should subscribe to the list, will be easier to keep the discourse pen ;) About Activities - detail: switch Add spacer button on the Panel menu with Activities button on the Add Widgets menu (reason is clear: Tool Box Activities | Panel Tool Box Activities | Spacer = Widget) http://simplest-image-hosting.net/png-0-panelmenu47 http://simplest-image-hosting.net/png-0-panelwidget47 These mock-ups are not mocking! well, the fact that the spacer is a widget is quite an implementation detail... i would like someting more intuitive to what we have now tough.. About Tool Box - There's a huge practical problem with the Tool Box: it must not be covered by windows. That's a good reason (and a good idea!) why it should there is the problem of multi monitor, but yes, something worth exploring be moved to Krunner. - could be a bonus to automatically launch Krunner when switching to a Dashboard? could be a good idea yes, or even having it with the lineedit always visible Devil said.. Next version of OsX will feature the fusion of Dashboard, Application launching and Expose in a single central place. it's fun how an application launching interface in dashboard (a SAL) is possible to do in kde since some time, we should really market more our innovations ;) And now, a geek story. Since 2 years my pc is a 10 netbook. After infinite geeky tweaks, I've found 2 perfect setups: 1) will be Unity compiz-3d / Unity qt-2d (currently using the latter) 2) Plasma Desktop + Windows can cover Panel + Menubars not shown + Present windows My computing is 3 things: (1) launching apps: + merging launchers into the taskbar has been a total success for me + krunner is great yes, launchers into taskbar just landed in 4.6, has to be polished a lot now ;) - what do I need more? Kickoff polish. or, pretty much maintaining it while making krunner so great kickoff won't be needed... (2) finding docs: + hierarchical browsing in Dolphin + Recently used tab in Kickoff + Folder view plasmoid (krunner+Nepomuk? no. 99% of the times I don't remember the file name. nepomuk is demanding for a netbook, strigi pure luxury) right now nepomuk is demanding de to some tecnical problems in both nepomuk itself and their upstream (virtuoso): it should get way better in the future. Thanks for your attention, good day Alex Ps. the end of my previous email has been cut after being sent.. http://simplest-image-hosting.net/png-0-panel47 http://simplest-image-hosting.net/png-0-panelmenu47 http://simplest-image-hosting.net/png-0-panelwidget47 http://simplest-image-hosting.net/png-0-kickoff47 nice mockups :) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: tokamak five
I can do April, but not before 11th. what we want to do, what the architecture of libplasma2 could be.. (good news, Bring the aspirins for this one :) location I propose something not in the Arctic circle :) Do we have something/someone in Vienna or similar? -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: tokamak five
On Thursday, February 3, 2011, Marco Martin wrote: Hi all, It seems it's that time of the year again :) I would really like we could have a little meeting again, maybe around april? I tink this time it would be nice to hae few people (10-15? but i want at least a couple of new faces there ;) to lay down a plan for the i think 15 even might be a bit too much for this one. i'd really enjoy a smaller, more focused Tokamak this time around. 10-12 is a good target imho. 3 new faces minimum, leaving a maximum of 9 old guard? we should have at least one kwin dev (more welcome), nepomuk would be nice to have there ... next releases, what we want to do, what the architecture of libplasma2 could be.. (good news, will have a way lower entry point barrier;) =) sooo some ideas abut * topics QML+JS, plasma-desktop circa jan 2012, plasma mobile and libplasma2 should be PLENTY, no? these topics are all related, overlap in significant ways and are key to 2011, imho. activities would get pulled in by plasma-desktop and mobile, as would some other topics like spiffying up the tasks widget and thinking about kickoff. * dates if it's in April, it can't be in the middle of the month for me. the beginning or end of April work, though. * location? (that's the tricky part, eheh ;) indeed; we could put out a call for hosts on our blogs? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
On Thursday, February 3, 2011, alex.tolar wrote: Good night everybody, I'm not using Windows since Ubuntu Dapper Drake, and Macintosh since before the colored iMacs: can't care less. Win7, OsX, Gnome3, Unity and many minor distros adopted a Dock: maybe not for a fool reason at all. I'm not well, tbh, it's something like this: * MacOS uses a dock * it becomes an object of desire * Microsoft freaks out, does what it does: copies * Canonical wants to become an object of desire, mimics Mac in many ways i don't think there's been a lot of critical thinking about dock usage. in fact, the mac dock was roundly criticized when it came out by usability folks. i'm not dead set against a dock, but i am against doing something because it's a trend. and with docks, that's what we have here. possibilities and polish. The great game, probably, is setting then the defaults. :) yes :) http://simplest-image-hosting.net/png-0-bitterock About having an icon-only launcher/task manager on the panel: there are 3 GREAT benefits: 1) Single-instance applications - Why having 4 Dolphins instances when you have tabs support? because i -want- two windows open? Talking also about memory resources! many multi-window apps are single process these days. - It's not pleasant to accidentally run 2 instances of Amarok or Skype amarok is a single instance app, skype is just plain broken. 2) Friendly to touchscreens, which are probably the future. if the number of items is kept to a minimum, yes. 3) Last, but not least: ditching the Application status icons! that's doable with the current tasks widget as well, so this isn't a benefit of a dock. About Tool Box - There's a huge practical problem with the Tool Box: it must not be covered by windows. That's a good reason (and a good idea!) why it should be moved to Krunner. it configures something that is covered by windows though :) keeping controls contextual is important imo - could be a bonus to automatically launch Krunner when switching to a Dashboard? interesting idea to try out... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: tokamak five
Quoting Marco Martin notm...@gmail.com: Hi all, It seems it's that time of the year again :) And that is great! :) I would really like we could have a little meeting again, maybe around april? I tink this time it would be nice to hae few people (10-15? but i want at least a couple of new faces there ;) to lay down a plan for the next releases, what we want to do, what the architecture of libplasma2 could be.. (good news, will have a way lower entry point barrier;) New faces interested in this? Please, show up! :) sooo some ideas abut * topics Aaron pointed most of the topics in my mind already. I would just include plasma/kde components as a way to prepare for the Platform sprint in June... * dates April sounds nice... * location? (that's the tricky part, eheh ;) I can probably offer our offices in Recife but probably it's a little too far for everybody else besides me and darktears :P However that would reach our goal of making aseigo fly over the Atlantic for the tokamak, now that he is located in Europe! :D Cheers, Artur PS: I cant wait to meet everybody again :P --- ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
apply buttons in config dialogs
hi.. some may have noticed that i enabled the apply button by default in widget config dialogs. i found a cute little hack to make the apply buttons deactivate properly on ok/apply being hit. (or so i hope :) now what we need to do is run around to all the C++ plasmoids and connect the widgets in their config dialogs to the settingsModified() slot in the KConfigDialog* that is passed in.. something like this: connect(uiDisplay.labelEdit, SIGNAL(textChanged(QString)), parent, SLOT(settingsModified())); connect(uiDisplay.flowCombo, SIGNAL(currentIndexChanged(int)), parent, SLOT(settingsModified())); connect(uiDisplay.sizeSlider, SIGNAL(valueChanged(int)), parent, SLOT(settingsModified())); connect(uiDisplay.showPreviews, SIGNAL(toggled(bool)), parent, SLOT(settingsModified())); i've put it on the tasks page and we can start listing all the ones that are finished as we go right here: http://community.kde.org/Plasma/Tasks#config_dialogs cheers ... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: Accessible Label (1/3)
On Thu, 2011-02-03 at 16:24 +0100, Sebastian Kügler wrote: On the other hand, it requires application developers to add another string in their code to all UI elements -- something which might be easily forgotten by those that don't care a lot about a11y (I fear that this applies to a lot of developers). Falling back to the tooltip sounds like something sensible for those cases. In any case, we should clearly document why it makes sense (justifies the extra work for developers and translators), so people actually do it. Additionally, some guidelines how to make those accessible labels useful, i.e. not just repeat the tooltip, but making it convey the needed information in a form suitable for screen readers. The overhead of such a thing is non-trivial, but I can't really judge the importance to a11y, so the above are just some thoughts about this proposed property. I agree documenting the purpose and providing ways for developers to realize when they're not given is key. I think another thing that is important is providing a documented path for adding them. Then someone who did use the strings could provide patches to projects which provided inadequate descriptions. --Ted signature.asc Description: This is a digitally signed message part ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New properties for StatusNotifierItem: (Not|Only)ShowIn (2/3)
On Thursday, February 3, 2011, Ted Gould wrote: On Thu, 2011-02-03 at 09:19 -0800, Aaron J. Seigo wrote: What we'd like to add is two properties that are lists of strings: NotShowIn and OnlyShowIn. These would work exactly the same as the same properties in Desktop files where an application could say NotShowIn=[Unity Launcher] and ensure that they'd never end up with that item used as a quicklist. this makes for a great hack to customize apps for a specific shell. unfortunately for the app developer (and their users) when that shell is replaced, then things go to hell all over again. Well, exactly. I think that if you're using this feature you're expecting to be very closely tied with a specific visualization and you need to expect things to break when that changes. when there are ways to avoid that scenario, how does it not strike you as a rediculously bad design for 3rd party developers? unless you aren't targetting 3rd party developers, of course *shrug* We can't expect to be robust for customized results over time, but providing a way for people who want to tweak specific visualizations with known short term results should be possible. if you are designing and developing the entire system yourself from top to bottom, this can work. if you have 3rd party developers involved, this is an amazingly bad idea. why? because the 3rd party app and the shell do not have the same timelines. unless every app and every shell release on the same day with the same UI support, it gets increasingly chaotic over time. it's also the definition of non-portable at the UI level; as someone with no vested interest in a specific platform, i have no interest in that. On Thu, 2011-02-03 at 10:43 -0800, Aaron J. Seigo wrote: On Thursday, February 3, 2011, Ted Gould wrote: people wanting different menus on the panel vs. on the launcher. crazy idea: different menus from the same SNI for different (well-defined in the spec) contexts? if the SNI only provides a generic menu, use that everywhere. if they provide a launcher menu, use that for launchers? we'd need a set of menu contexts (generic or primary controller, launcher, ..?) That seems to me to be attaching the spec more directly to specific visualizations. Which, honestly, I'd like to discourage overall. but Not/Only which list specific visualizations is not tieing it to specific visualizations? c'mon :) generic profiles of this is appropriate for launchers, this is a full featured menu (or whatever divisions we decide to come up with) would not be visualization specific in the least. it would be defining use cases for application developers to fill with visualizations selecting which one(s) match their display needs. and then any number of visualizations can take advantage of that work and app developers can rest easy that their hard work isn't going to get torn up 2 years from now (ditto for users, who are even more powerless in this) Also, in our specific case there are more restrictions on the menus in the launcher (no submenus) so if an app wanted to use those they wouldn't want it to appear in the launcher. this can be determined with a heuristic? You don't know what people would want to do when the submenu was removed. In some cases you might want to do something like: ah, so you don't want to just hide them but also perhaps manipulate them. which would be solvable with the multiple menus approach. for Canonical, you have Unity today but in 5 years what will you have? maye something different. it's probably better not to get a whole bunch of app code specific to today's Unity design that in N years you're going to have to either provide legacy support for (probably with hacks) or which will result in having to re-work all those apps .. again. for KDE, it's even trickier: we don't have just one to-market product to support. different vendors ship Plasma in different forms and configurations, so we have to deal with instant legacy whenever these kinds of features are introduced. I guess I look at this similar to writing assembly code. Do we allow developers to write assembly if needed? Yes, we do. Is it discouraged? Yeah. it's not discouraged at all. it's there for use when the problem requires it. other tools are there for when the problem doesn't require it. in this case, the tool isn't needed as long as we design SNI with consistent principles. what you want is not impossible with a clear data/visualization division. it just takes more up-front design thinking. in the long run it will save oodles of app developer time and UI inconsistencies down the road. measure twice, cut once. Certainly customized designs for specific visualizations increase development time, maintenance cost and testing. That doesn't mean that we shouldn't make it impossible if that level of optimization is required. we should if it will lead to abuse
Re: the next step on the desktop
- Ursprüngliche Mitteilung - On Thursday, February 3, 2011, alex.tolar wrote: Good night everybody, I'm not using Windows since Ubuntu Dapper Drake, and Macintosh since before the colored iMacs: can't care less. Win7, OsX, Gnome3, Unity and many minor distros adopted a Dock: maybe not for a fool reason at all. I'm not well, tbh, it's something like this: * MacOS uses a dock * it becomes an object of desire * Microsoft freaks out, does what it does: copies * Canonical wants to become an object of desire, mimics Mac in many ways i don't think there's been a lot of critical thinking about dock usage. in fact, the mac dock was roundly criticized when it came out by usability folks. i'm not dead set against a dock, but i am against doing something because it's a trend. and with docks, that's what we have here. I'm really, really against docks. Mac has constructed their complete workflow around the dock system. Their window system supports it - our dosn't. The best we can get is a bad copy and we can do better. Let's not copy the dock but make tasks bar better. Cheers Martin possibilities and polish. The great game, probably, is setting then the defaults. :) yes :) http://simplest-image-hosting.net/png-0-bitterock About having an icon-only launcher/task manager on the panel: there are 3 GREAT benefits: 1) Single-instance applications - Why having 4 Dolphins instances when you have tabs support? because i -want- two windows open? Talking also about memory resources! many multi-window apps are single process these days. - It's not pleasant to accidentally run 2 instances of Amarok or Skype amarok is a single instance app, skype is just plain broken. 2) Friendly to touchscreens, which are probably the future. if the number of items is kept to a minimum, yes. 3) Last, but not least: ditching the Application status icons! that's doable with the current tasks widget as well, so this isn't a benefit of a dock. About Tool Box - There's a huge practical problem with the Tool Box: it must not be covered by windows. That's a good reason (and a good idea!) why it should be moved to Krunner. it configures something that is covered by windows though :) keeping controls contextual is important imo - could be a bonus to automatically launch Krunner when switching to a Dashboard? interesting idea to try out... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: tokamak five
- Ursprüngliche Mitteilung - On Thursday, February 3, 2011, Marco Martin wrote: Hi all, It seems it's that time of the year again :) I would really like we could have a little meeting again, maybe around april? I tink this time it would be nice to hae few people (10-15? but i want at least a couple of new faces there ;) to lay down a plan for the i think 15 even might be a bit too much for this one. i'd really enjoy a smaller, more focused Tokamak this time around. 10-12 is a good target imho. 3 new faces minimum, leaving a maximum of 9 old guard? we should have at least one kwin dev (more welcome), nepomuk would be nice to have there ... I will come and I already talked to San from Compiz and he would like to join if time permitts. And he would be a new face. next releases, what we want to do, what the architecture of libplasma2 could be.. (good news, will have a way lower entry point barrier;) =) sooo some ideas abut * topics better use of compositor in kwin and looking into the transition to Wayland. * dates if it's in April, it can't be in the middle of the month for me. the beginning or end of April work, though. April is fine for me. Beginning of May might be difficult. * location? (that's the tricky part, eheh ;) indeed; we could put out a call for hosts on our blogs? Something in central europe would be nice :-) Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
