Re: Review request: Container plasma applet
On Monday 28 September 2009 05:20:06 Aaron J. Seigo wrote: first thought i have is that if there are different svg's for different sizes, let's put those different svg's in a file and use them. Yup! I think that Marco is a bit too much optimistic too, but details follow in the mail answering to him. This could work by letting the air/oxygen theme embed the battery as pngs in the theme. It still doesn't solve the problems of consistency with the menu and device notifier which are themed by the icon theme, and the configuration of icon effects, but it's still a step forward. but i think we should stop thinking in terms of we have 16, 22, 32, 48, 64, 128 and 256 px interfaces that is implied in this whole thread about using bitmaps. we have 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 250, 251, 252, 253, 254, 255, 256 px interfaces. Interfaces do work at those sizes, some of them slightly less good than fixed sizes, but certainly better than blindly scaling svgs. png scaling *does* work reasonably well for most cases, for example the menu and the device notifier haven't ever shown me a scaling artifact in the panel. SVGs need a lot of love to be done right, just like scalable interfaces. or, more simply, to put it like nuno always says: SVG is not scalable! whoever tells you that is lying! if the svg's only look good at certain multiples then we need to keep the resizing to within those multiples. Ok, then I think it's fair not to let the battery grow over 256x256. Even if it could probably be scaled a little bit more up without loosing too much details. :-) but really, going to pixmaps is not an option for reasons that should really be abundantly clear to anyone who has written a plasmoid. So, are you suggesting that for example device notifier and the menus should switch over to SVG? Bye, -Riccardo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
On Sunday 27 September 2009 23:19:41 Sebastian Kügler wrote: [...] The problem might be that the battery.svg has not been touched by an artist in two years. I've hacked an icon's SVG from lng ago into the battery.svg theme. I'm bad at Inkscape today, and I certainly had any concept of pixel alignment that time. :/ This is only part of the issue (bad graphics used), the other part is shortcomings in Qt and SVG sizing for smaller pixel sizes. Don't worry, the svg is just the same as the one of the oxygen icons. :-) then you have right effects applied like icon colorizing (try to make all your icons pink and you'll know what i mean) which nowadays breaks for the standard panel just for the battery. current animation is also somewhat... not very professional, at least in my humble opinion, i think that fading in and out the flashlight would look just so much better. That's a one or two line change. Agreed, I think we should do it, but here I was just saying that the current animation is not a problem. :-) and i don't think it's a showstopper anyways. theme appropriateness then isn't really a problem too, no other icon on the panel infact respects it, and i think they do the right thing here. I don't. I'd *love* to see a monochrome system tray, that's hard to do right now, except for the battery plasmoid because it's using plasma's theme support. The battery applet supports that currently without any code changes. See my previous answer to marco here. I'd love a monochrome icon too, but users *are* going to use 3rd party applications no matter what, with icons on which we have no control onto. If we ever manage to split hardware/system icons and apps then I'm all for it. :-) infact i think it's a bad idea to make the theme able to change these icons, after all to the user they're all system icons, icons like systray icons, or the menu or the device notifier. as such we have two possibilities: a) make the plasma theme theme all the icons, including systray and menu b) leave that up to the icon theme You're still thinking of the system tray as an icon parade. ;-) Having things like the battery in the system tray as an icon, but I would rather not have this limit the rendering of it to just the sizes KIconLoader supports. Well, KIcon scales pngs so that's not really a problem. Of course the scaled sizes don't look as well as prerendered svgs, but that always gave us good enough resutls until now. :-) From a theming point of view, themers can currently just grab the battery.svg and change it. Also, using KIcon would mean that we need 120 different icons (10*2 states, 6 sizes), that sounds like an awful lot of disk I/O and clutter to me. Hmm... we already have all those icons, I counted 10 because i tend to consider the sizes as implicit, but anyways, they aren't going to be shown all at once. I think it's reasonably fast to load pngs, and because they're all cached, i don't think it's any slower than what it is now with svg caching. :-) a is not really feasible though, not only because we give a lot more images to do to theme creator, but then we lose the ability to do cool effects (blur) because of the crappy svg renderer. even if we do embed pngs, we loose the ability of having multiple sizes pngs, discarding all the work done on small size icons. that only leaves b as an option. [...] As I explained above, it's really not that. :-) It's borders, grid alignment, and other style issues. Some of those can really be fixed in the SVG file, can you have a look at that? Hm, I'm not really sure, as Marco correctly explains, we can't really fix everything there. It's hard to do small sizes, we have one artist (david miller) who is almost completely dedicated to that, if you want to have a look at how much the icons do change, look in the small/16x16 directory of the oxygen sources. :-) To summarize a bit what we have right now: - pixel alignment - Qt SVG rendering issues +1 - bad quality of battery.svg nah, not battery.svgz, i think we can't get much better than that :-) It's oxygen after all! :P + animations + theming (monochrome / color, at least) + 'just one theme file' +1 Bye, -Riccardo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
On Sunday 27 September 2009 23:58:56 Marco Martin wrote: to summarize, here there are 3 problems: i don't think good pixel alignment could be reached using just svg, no matter how good the renderer is (unless we will have someday something as crazy as the truetype hinting language, something that i don't see in the near future, not even desiderable, probably), oxygen icons are mostly redrawn from scratch or at least adapted for different resolutions, because they're different beasts and shapes have to be quite different (hopefully when we'll have 300+ dpi monitors the problem will solve itself :D). +1 however, with svg we can have an image that can look good at a certain size (the default systray size?) and its multiples, and could be good enough (now the battery svg is not that bad, the only reall bad bit is the little lighting that signales ac plugged in, but that's fixable). if it will still use svg, just one thing is important to do: now resizing the battery it gets stretched in funny ways. it should retain its aspect ratio and be painted in the largest proportioned rect contained in the applet contents rect. should be quite a small patch. I think that while your analisys is correct, you're a bit too much optimistic, because you forgot something. ;-) To keep a long story short, I think this works perfectly for icons 32x32, but for smaller sizes details have to be removed and strokes thikened, so when rendering the svgs at its multiples you end up with way too thick borders and incorrect icons. :\ last thing, monocrome systray: since it's really simple probably svgs are enough in this case too, for plasmoids would be a bit tricky, because they should have to detect if they are in the systray and change their svg accordingly. for the new systray protocol icons, if they use icon names as opposed to pixmaps it is ridicolously easy: just find that name in the plasma theme, if not found use kicon as usual, for old icons, well, another reason to port it yup, that'd rock! :-) Bye, -Riccardo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
On Sunday 27 September 2009 21:10:44 Marco Martin wrote: this depends from the idea of having in the systray having only system and hardware items, with all applications moved in the taskbar and maybe the network ones in some kind of different area... otherwise yes, wouldn't look particularly good so yes, it could be deferred until (and if) some more work on that direction a huge +1 i totally agree that would be a great solution! -Riccardo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
On Monday 28 September 2009 16:44:09 Riccardo Iaconelli wrote: - bad quality of battery.svg nah, not battery.svgz, i think we can't get much better than that :-) It's oxygen after all! :P Have you actually opened the file in inkscape and looked at it? Even Nuno told me repeatedly that it's crap. Can't argue with that. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 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: Container plasma applet
On Monday 28 September 2009 17:06:07 Sebastian Kügler wrote: Have you actually opened the file in inkscape and looked at it? Even Nuno told me repeatedly that it's crap. Can't argue with that. Maybe he was talking of something else? Like the rendering in the panel? I confirm that's the oxygen battery! (and infact is even pixel perfect at 64x64 :-) ) Bye, -Riccardo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
On Thursday 24 September 2009 19:22:57 Aaron J. Seigo wrote: how is this any different other than the SVG being pre-rendered vs rendered at runtime? how would we provide for nice sizing? and how would the animations that exist currently be implemented, such as the power indicator zoom in? theme appropriateness? Well, the pre-rendered png has pixel perfectionness and a number of other retouches. Just for the most evident detail, if you look at the real pngs you can see that the battery bg of the rendered svg is much more blurry than what's intented to be.[1] then you have right effects applied like icon colorizing (try to make all your icons pink and you'll know what i mean) which nowadays breaks for the standard panel just for the battery. current animation is also somewhat... not very professional, at least in my humble opinion, i think that fading in and out the flashlight would look just so much better. and i don't think it's a showstopper anyways. theme appropriateness then isn't really a problem too, no other icon on the panel infact respects it, and i think they do the right thing here. infact i think it's a bad idea to make the theme able to change these icons, after all to the user they're all system icons, icons like systray icons, or the menu or the device notifier. as such we have two possibilities: a) make the plasma theme theme all the icons, including systray and menu b) leave that up to the icon theme a is not really feasible though, not only because we give a lot more images to do to theme creator, but then we lose the ability to do cool effects (blur) because of the crappy svg renderer. even if we do embed pngs, we loose the ability of having multiple sizes pngs, discarding all the work done on small size icons. that only leaves b as an option. to conclude, because of the svg it behaves differently from all other default panel buttons, looks worse, and in the end it only gives a sense of inconsistency to the user. that's why i feel it should be a kicon. isn't the problem really that it doesn't draw the SVG with proper sizes all the time? i think the painting of the widget could be re-written with today's Plasma and Qt stuff much cleaner and resolve the outstanding issues. As I explained above, it's really not that. :-) It's borders, grid alignment, and other style issues. Bye, -Riccardo [1] i kind of remember there has an attempt to make a power manager in kubuntu, with 4.1 i think, they used the systray with the correct icons, and you could really see how much better it looked. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
On Sunday 27 September 2009, Riccardo Iaconelli wrote: On Thursday 24 September 2009 19:22:57 Aaron J. Seigo wrote: how is this any different other than the SVG being pre-rendered vs rendered at runtime? how would we provide for nice sizing? and how would the animations that exist currently be implemented, such as the power indicator zoom in? theme appropriateness? Well, the pre-rendered png has pixel perfectionness and a number of other retouches. Just for the most evident detail, if you look at the real pngs you can see that the battery bg of the rendered svg is much more blurry than what's intented to be.[1] then you have right effects applied like icon colorizing (try to make all your icons pink and you'll know what i mean) which nowadays breaks for the standard panel just for the battery. current animation is also somewhat... not very professional, at least in my humble opinion, i think that fading in and out the flashlight would look just so much better. and i don't think it's a showstopper anyways. theme appropriateness then isn't really a problem too, no other icon on the panel infact respects it, and i think they do the right thing here. infact i think it's a bad idea to make the theme able to change these icons, after all to the user they're all system icons, icons like systray icons, or the menu or the device notifier. as such we have two possibilities: a) make the plasma theme theme all the icons, including systray and menu speaking of wich, i woud really like to have some systray icons dependent from the plasma theme (i.e. mostly monochrome systray, but this should look totally different between air and oxygen for instance. (and with the new protocol this could become really easy) probably the amount of graphics needed wouldn't be huge, because it would make sense only icons of hardware and system categories, so, battery, kmix, networkmanager, maybe strigy and stuff like that b) leave that up to the icon theme a is not really feasible though, not only because we give a lot more images to do to theme creator, but then we lose the ability to do cool effects (blur) because of the crappy svg renderer. even if we do embed pngs, we loose the ability of having multiple sizes pngs, discarding all the work done on small size icons. that only leaves b as an option. to conclude, because of the svg it behaves differently from all other default panel buttons, looks worse, and in the end it only gives a sense of inconsistency to the user. that's why i feel it should be a kicon. isn't the problem really that it doesn't draw the SVG with proper sizes all the time? i think the painting of the widget could be re-written with today's Plasma and Qt stuff much cleaner and resolve the outstanding issues. As I explained above, it's really not that. :-) It's borders, grid alignment, and other style issues. Bye, -Riccardo [1] i kind of remember there has an attempt to make a power manager in kubuntu, with 4.1 i think, they used the systray with the correct icons, and you could really see how much better it looked. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
On Sunday 27 September 2009 15:32:27 Marco Martin wrote: speaking of wich, i woud really like to have some systray icons dependent from the plasma theme (i.e. mostly monochrome systray, but this should look totally different between air and oxygen for instance. (and with the new protocol this could become really easy) probably the amount of graphics needed wouldn't be huge, because it would make sense only icons of hardware and system categories, so, battery, kmix, networkmanager, maybe strigy and stuff like that Hmm... I had the same idea, but I still have to think about it. It's better to have a couple of good ones and all the others looking completely out of place, or have the systray look like a happy rio carnival? mhh :-) Bye, -Riccardo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
On Sunday 27 September 2009, Sebastian Kügler wrote: On Sunday 27 September 2009 15:01:42 Riccardo Iaconelli wrote: On Thursday 24 September 2009 19:22:57 Aaron J. Seigo wrote: how is this any different other than the SVG being pre-rendered vs rendered at runtime? how would we provide for nice sizing? and how would the animations that exist currently be implemented, such as the power indicator zoom in? theme appropriateness? Well, the pre-rendered png has pixel perfectionness and a number of other retouches. Just for the most evident detail, if you look at the real pngs you can see that the battery bg of the rendered svg is much more blurry than what's intented to be.[1] The problem might be that the battery.svg has not been touched by an artist in two years. I've hacked an icon's SVG from lng ago into the battery.svg theme. I'm bad at Inkscape today, and I certainly had any concept of pixel alignment that time. :/ This is only part of the issue (bad graphics used), the other part is shortcomings in Qt and SVG sizing for smaller pixel sizes. then you have right effects applied like icon colorizing (try to make all your icons pink and you'll know what i mean) which nowadays breaks for the standard panel just for the battery. current animation is also somewhat... not very professional, at least in my humble opinion, i think that fading in and out the flashlight would look just so much better. That's a one or two line change. and i don't think it's a showstopper anyways. theme appropriateness then isn't really a problem too, no other icon on the panel infact respects it, and i think they do the right thing here. I don't. I'd *love* to see a monochrome system tray, that's hard to do right now, except for the battery plasmoid because it's using plasma's theme support. The battery applet supports that currently without any code changes. infact i think it's a bad idea to make the theme able to change these icons, after all to the user they're all system icons, icons like systray icons, or the menu or the device notifier. as such we have two possibilities: a) make the plasma theme theme all the icons, including systray and menu b) leave that up to the icon theme You're still thinking of the system tray as an icon parade. ;-) Having things like the battery in the system tray as an icon, but I would rather not have this limit the rendering of it to just the sizes KIconLoader supports. From a theming point of view, themers can currently just grab the battery.svg and change it. Also, using KIcon would mean that we need 120 different icons (10*2 states, 6 sizes), that sounds like an awful lot of disk I/O and clutter to me. a is not really feasible though, not only because we give a lot more images to do to theme creator, but then we lose the ability to do cool effects (blur) because of the crappy svg renderer. even if we do embed pngs, we loose the ability of having multiple sizes pngs, discarding all the work done on small size icons. that only leaves b as an option. to conclude, because of the svg it behaves differently from all other default panel buttons, looks worse, and in the end it only gives a sense of inconsistency to the user. that's why i feel it should be a kicon. isn't the problem really that it doesn't draw the SVG with proper sizes all the time? i think the painting of the widget could be re-written with today's Plasma and Qt stuff much cleaner and resolve the outstanding issues. What would those changes be? As I explained above, it's really not that. :-) It's borders, grid alignment, and other style issues. Some of those can really be fixed in the SVG file, can you have a look at that? To summarize a bit what we have right now: - pixel alignment - Qt SVG rendering issues - bad quality of battery.svg + animations + theming (monochrome / color, at least) + 'just one theme file' to summarize, here there are 3 problems: i don't think good pixel alignment could be reached using just svg, no matter how good the renderer is (unless we will have someday something as crazy as the truetype hinting language, something that i don't see in the near future, not even desiderable, probably), oxygen icons are mostly redrawn from scratch or at least adapted for different resolutions, because they're different beasts and shapes have to be quite different (hopefully when we'll have 300+ dpi monitors the problem will solve itself :D). however, with svg we can have an image that can look good at a certain size (the default systray size?) and its multiples, and could be good enough (now the battery svg is not that bad, the only reall bad bit is the little lighting that signales ac plugged in, but that's fixable). if it will still use svg, just one thing is important to do: now resizing the battery it gets stretched in funny ways. it should retain its
Re: Review request: Container plasma applet
On September 27, 2009, Marco Martin wrote: i don't think good pixel alignment could be reached using just svg, no matter how good the renderer is (unless we will have someday something as crazy as the truetype hinting language, something that i don't see in the near future, not even desiderable, probably), oxygen icons are mostly first thought i have is that if there are different svg's for different sizes, let's put those different svg's in a file and use them. but i think we should stop thinking in terms of we have 16, 22, 32, 48, 64, 128 and 256 px interfaces that is implied in this whole thread about using bitmaps. we have 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 250, 251, 252, 253, 254, 255, 256 px interfaces. if the svg's only look good at certain multiples then we need to keep the resizing to within those multiples. but really, going to pixmaps is not an option for reasons that should really be abundantly clear to anyone who has written a plasmoid. -- 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: Review request: Container plasma applet
On Wednesday 23 September 2009 10:11:19 Marco Martin wrote: this means those plasmoids have to be fixed. in particular the battery applet should have a constrainedsquare aspect ratio andstill draw the svg as square when the applet is rectangular Hm... to be sincere, I think that the battery plasmoid should just be converted to use KIcon to draw the battery, not an SVG. This for example ensures that it's not the only icon in the panel which is not colorized or affected by configuring effects in the control center (e.g. if you choose to make all your icons pink) :-) And it just looks better... Bye, -Riccardo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
On Thursday 24 September 2009, Riccardo Iaconelli wrote: On Wednesday 23 September 2009 10:11:19 Marco Martin wrote: this means those plasmoids have to be fixed. in particular the battery applet should have a constrainedsquare aspect ratio andstill draw the svg as square when the applet is rectangular Hm... to be sincere, I think that the battery plasmoid should just be converted to use KIcon to draw the battery, not an SVG. This for example ensures that it's not the only icon in the panel which is not colorized or affected by configuring effects in the control center (e.g. if you choose to make all your icons pink) :-) And it just looks better... Bye, -Riccardo agree, and should use just icons in standard sizes like the pastebin applet -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
On September 24, 2009, Riccardo Iaconelli wrote: On Wednesday 23 September 2009 10:11:19 Marco Martin wrote: this means those plasmoids have to be fixed. in particular the battery applet should have a constrainedsquare aspect ratio andstill draw the svg as square when the applet is rectangular Hm... to be sincere, I think that the battery plasmoid should just be converted to use KIcon to draw the battery, not an SVG. how is this any different other than the SVG being pre-rendered vs rendered at runtime? how would we provide for nice sizing? and how would the animations that exist currently be implemented, such as the power indicator zoom in? theme appropriateness? isn't the problem really that it doesn't draw the SVG with proper sizes all the time? i think the painting of the widget could be re-written with today's Plasma and Qt stuff much cleaner and resolve the outstanding issues. -- 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: Review request: Container plasma applet
On 9/23/09, alan moore m...@alandmoore.com wrote: Anyway, with your last sentence you was saying that I could have done a similar thing working directly on containments? yes, and that's really probably the way to go about it. use cases would probably help define what direction to actually take. I was actually a bit excited when I saw this applet myself, as I had looked into developing something along the same lines (but gave up because I didn't have the requisite coding knowledge). Basically, my use case is simple: using the KDE panel as a sidebar. The reason being that screens are getting wider and smaller for many users (think notebooks, netbooks, UMPCs), vertical space becomes more valuable, so it makes sense to put stuff like the panel (that mostly just sits there offering some controls) off to the side rather than the traditional top/bottom arrangement. When I tried this with my panel as-is, the results were problematic. Many plasmoids (such as the battery monitor) insist on being square, and in a 200 to 300 px wide sidebar they take up a huge amount of space. Some just kind of fall apart. The tray became a huge squarish thing that took up 1/4 of the height. this means those plasmoids have to be fixed. in particular the battery applet should have a constrainedsquare aspect ratio andstill draw the svg as square when the applet is rectangular My thinking for the solution was to create a sub-containment that would allow plasmoids to be arranged in horizontal rows on a vertical sidebar. best bapproach would be write a panel containment that allows more complex layouts, like vertval layout of horizontals or more simply a grid layout I don't know if the plasmoid in question can do that, or if the panel can be modified to do that, but it seems a reasonable way to approach the problem. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
Aaron J. Seigo wrote: On September 22, 2009, alan moore wrote: My thinking for the solution was to create a sub-containment that would and improving the panel and/or the widgets wasn't a possibility? :) Possible, but for me not very probable; I'm just a simple python hacker. Though I did think about submitting a detailed wishlist item with mockups, etc. In the end it seemed like proof-of-concept code seemed like a better path, but even that was beyond me. I'm sure the best solution is to work the capabilities into the panel. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
Anyway, with your last sentence you was saying that I could have done a similar thing working directly on containments? yes, and that's really probably the way to go about it. use cases would probably help define what direction to actually take. I was actually a bit excited when I saw this applet myself, as I had looked into developing something along the same lines (but gave up because I didn't have the requisite coding knowledge). Basically, my use case is simple: using the KDE panel as a sidebar. The reason being that screens are getting wider and smaller for many users (think notebooks, netbooks, UMPCs), vertical space becomes more valuable, so it makes sense to put stuff like the panel (that mostly just sits there offering some controls) off to the side rather than the traditional top/bottom arrangement. When I tried this with my panel as-is, the results were problematic. Many plasmoids (such as the battery monitor) insist on being square, and in a 200 to 300 px wide sidebar they take up a huge amount of space. Some just kind of fall apart. The tray became a huge squarish thing that took up 1/4 of the height. My thinking for the solution was to create a sub-containment that would allow plasmoids to be arranged in horizontal rows on a vertical sidebar. I don't know if the plasmoid in question can do that, or if the panel can be modified to do that, but it seems a reasonable way to approach the problem. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
On September 22, 2009, alan moore wrote: My thinking for the solution was to create a sub-containment that would and improving the panel and/or the widgets wasn't a possibility? :) -- 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: Review request: Container plasma applet
On September 20, 2009, Giulio Camuffo wrote: I've added in kdereview/plasma/applets an applet i made recently. It is, as the name suggests, an applet that lets you contain and group other applets. this functionality belongs in a Containment, not an Applet. we have two applets right now that can contain other applets: system tray and system monitor. the latter has had numerous bugs and is, to be frank, an implementation mistake. there is nothing that could not have been done much easier and with less hacking around stuff if system monitor had not been written to embed the various system monitor applets directly. the design of Plasma is such that the Containment-Applet relationship is quite carefully crafted and solves a lot of issues. ContainerWidget::drop which does not support various features found in Containment is a good example of this. i think it's a nice candidate for publishing on kde-look.org and you can certainly put it into extragear if you'd like, but the concept is problematic from a design perspective and will cause inconsistencies and other problems if we ship it with Plasma. given Containments have complete freedom on how to manage, group, etc. Applets, focusing these kinds of efforts there would make a lot more sense. -- 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: Review request: Container plasma applet
I know that that functionality belongs in a Containment, but since containments in containments are not supported i had to use an Applet. And i know that this applet will never have all the functionalities the containments have, but this isn't my goal. I wanted to develop a simple applet to group other applets. I don't plan to implement e.g. the new feature that loads the applet depending on the mimetype dropped. I developed this also because I thought to do a plasmoid that was actually a set of plasmoids inserted in this applet. But if you say that this brings many bugs and headaches amybe i'll change my mind. I don't understand however why the systemtray isn't problematic while this one it is. I already published it on kde-look, and I'd say people like it, since it is already 80% good with only 73 downloads, but I thought it would be more discoverable to the people if it was inside KDE, since, from what I read, some people need it. Anyway, with your last sentence you was saying that I could have done a similar thing working directly on containments? Giulio 2009/9/20 Aaron J. Seigo ase...@kde.org On September 20, 2009, Giulio Camuffo wrote: I've added in kdereview/plasma/applets an applet i made recently. It is, as the name suggests, an applet that lets you contain and group other applets. this functionality belongs in a Containment, not an Applet. we have two applets right now that can contain other applets: system tray and system monitor. the latter has had numerous bugs and is, to be frank, an implementation mistake. there is nothing that could not have been done much easier and with less hacking around stuff if system monitor had not been written to embed the various system monitor applets directly. the design of Plasma is such that the Containment-Applet relationship is quite carefully crafted and solves a lot of issues. ContainerWidget::drop which does not support various features found in Containment is a good example of this. i think it's a nice candidate for publishing on kde-look.org and you can certainly put it into extragear if you'd like, but the concept is problematic from a design perspective and will cause inconsistencies and other problems if we ship it with Plasma. given Containments have complete freedom on how to manage, group, etc. Applets, focusing these kinds of efforts there would make a lot more sense. -- 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
On Sunday 20 September 2009, 14:10 Giulio Camuffo wrote: I know that that functionality belongs in a Containment, but since containments in containments are not supported i had to use an Applet. Hmmare you sure that containments inside containments are not supported ? =( Cheers, -- Artur Duque de Souza openBossa INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net -- 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: Container plasma applet
On September 20, 2009 10:29:14 Artur Souza (MoRpHeUz) wrote: On Sunday 20 September 2009, 14:10 Giulio Camuffo wrote: I know that that functionality belongs in a Containment, but since containments in containments are not supported i had to use an Applet. Hmmare you sure that containments inside containments are not supported ? =( yes. -- This message brought to you by eevil bananas and the number 3. www.chani3.com 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: Container plasma applet
On Sunday 20 September 2009, Giulio Camuffo wrote: Hi! I've added in kdereview/plasma/applets an applet i made recently. It is, as the name suggests, an applet that lets you contain and group other applets. i'm just an ambassandor on that, but apparently it's missing Messages.sh You can put it on the desktop or on the panel and then drag other applets from the add applet widget inside it. it puts the applet in a grid layout and it uses a spacer like the one in the panel to tell you where the applet will be put if you release the mouse. Then you can move the applets inside the layout. It supports the drop and creation of icons plasmoid from the entries from kickoff too. When you put it in the panel you can choose, through a check box in the configuration dialog if you want it to behave like a PopupApplet or like a simple Applet. Currently it needs an icon, because the question mark you can see now if you use it as a PopupApplet isn't so cool. I searched through the icon chooser but I coul not find an icon that suited my taste. This plasmoid solves requests like https://bugs.kde.org/show_bug.cgi?id=193015 and others i saw on the bug tracker and on the brainstorm. Giulio. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
On Sunday 20 September 2009, Giulio Camuffo wrote: I know that that functionality belongs in a Containment, but since containments in containments are not supported i had to use an Applet. And i know that this applet will never have all the functionalities the containments have, but this isn't my goal. I wanted to develop a simple applet to group other applets. I don't plan to implement e.g. the new feature that loads the applet depending on the mimetype dropped. I developed this also because I thought to do a plasmoid that was actually a set of plasmoids inserted in this applet. But if you say that this brings many bugs and headaches amybe i'll change my mind. I don't understand however why the systemtray isn't problematic while this one it is. well, it's a bit problematic indeed actually, one of the reasons the config ui only permits to add a tiny supset of the applets, for 2 reasons what there could make sense from an user pov but most important excluding the ones that will break. (and have already to lie about the real formfactor to not make it explode in the desktop) I already published it on kde-look, and I'd say people like it, since it is already 80% good with only 73 downloads, but I thought it would be more discoverable to the people if it was inside KDE, since, from what I read, some people need it. Anyway, with your last sentence you was saying that I could have done a similar thing working directly on containments? Giulio 2009/9/20 Aaron J. Seigo ase...@kde.org On September 20, 2009, Giulio Camuffo wrote: I've added in kdereview/plasma/applets an applet i made recently. It is, as the name suggests, an applet that lets you contain and group other applets. this functionality belongs in a Containment, not an Applet. we have two applets right now that can contain other applets: system tray and system monitor. the latter has had numerous bugs and is, to be frank, an implementation mistake. there is nothing that could not have been done much easier and with less hacking around stuff if system monitor had not been written to embed the various system monitor applets directly. the design of Plasma is such that the Containment-Applet relationship is quite carefully crafted and solves a lot of issues. ContainerWidget::drop which does not support various features found in Containment is a good example of this. i think it's a nice candidate for publishing on kde-look.org and you can certainly put it into extragear if you'd like, but the concept is problematic from a design perspective and will cause inconsistencies and other problems if we ship it with Plasma. given Containments have complete freedom on how to manage, group, etc. Applets, focusing these kinds of efforts there would make a lot more sense. -- 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 -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review request: Container plasma applet
On September 20, 2009, Giulio Camuffo wrote: I don't plan to implement e.g. the new feature that loads the applet depending on the mimetype dropped. this kind of inconsistency is exactly what keeps this kind of approach out of the main modules. why should the user be allowed to only do certain things in certain places due to implementation decisions? nah.. :) the user should be able to trust the rules and not have to do special things for special circumstances. (the fact that you have to, in practice anyways, open the panel toolbox to configure the tasks widget still bugs me :P) I developed this also because I thought to do a plasmoid that was actually a set of plasmoids inserted in this applet. what kind of plasmoid, exactly? (we may have other ideas on how to achieve this) I don't understand however why the systemtray isn't problematic while this one it is. the system tray is problematic. it works around a number of little things (though we did make some changes internal to libplasma to ease that as well), but the benefits outweigh the negatives. the system monitor, however, has all the negatives and no real benefits. so it's a case by case basis, and generally discouraged because the chance for regressions are high when changes get made (esp new features) in libplasma. I already published it on kde-look, and I'd say people like it, since it is already 80% good with only 73 downloads, but I thought it would be more discoverable to the people if it was inside KDE, since, from what I read, some people need it. honestly, people rarely know what they really need or even really want. imagine if we removed folderview tomorrow? and that was the most Evil Feature Ever(tm) a year ago. design with purpose, not by the popular opinion and whims of those on kdelook or other online sites populated by self-selecting hard core users. Anyway, with your last sentence you was saying that I could have done a similar thing working directly on containments? yes, and that's really probably the way to go about it. use cases would probably help define what direction to actually take. -- 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
