Re: Review Request: Imgur support in Pastebin applet
On Mon, Jan 25, 2010 at 3:33 AM, Artur Souza (MoRpHeUz) morph...@openbossa.org wrote: On Sunday 24 January 2010, 12:24 Beat Wolf wrote: On 2009-12-05 10:26:00, Nikhil Marathe wrote: what is the status of this patch? well, it can go in. I can't do it *right now* but probably next week. Or be my guest if any of you can commit it :) I have commit access, so can I go ahead? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Prefetching in Comic Strip plasmoid
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2636/ --- (Updated 2010-01-25 10:19:38.683488) Review request for Plasma and Matthias Fuchs. Changes --- Added current maintainer to People list. Summary (updated) --- When a new strip is loaded, it caches both the previous and the next one, without interfering with the currently displayed comic. This is very useful if you're reading throug a particular comic, especially on slower connections. It's a two-line patch, but it greatly improves the experience for this use-case. Caching is done by the DataEngine, so no further modifications were needed. After a discussion in the mailing list, the decision was to have no configuration for this, as the cost of downloading a single picture is qiute low. Diffs - /trunk/KDE/kdeplasma-addons/applets/comic/comic.cpp 1075738 Diff: http://reviewboard.kde.org/r/2636/diff Testing --- I tested it on my Ubuntu machine with todays trunk. It works as expected, and I haven't noticed any regressions. Thanks, Miha ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notifications, again :D
Hey! +1 on that... having tons of notifications showing up at the same time is really distracting... I'd go with some vertical scrolling, but make sure the timeout time gets applied to each item when it is showing, not only when it's in the list... :) Lukas Am Montag 25 Januar 2010 13:20:56 schrieb Marco Martin: howdy all, so, based on both ersonal experience and feedbacks i'm of course stilkl not happy on how notifications work, that's the pretty hard question of being informative enough, vs not entirely cover the screen. last thing i was thinking about was something that resembles rssnow: http://imagebin.ca/view/fiFONCc.html this would resemble the pattern of the appletbrowser, search and launch and possibly other stuff in the future. -only one notification is shown at a time -still valid notifications scrolls automatically or after arrows press, like rssnow bottom arrow would switch from valid to recent expired notifications other options would be: -something similar but with vertical scrolling -leave as is now, but just displaying 2-3 otifications at a time, throwing away everything older (simpler ui, but loses significant informations) now, for the technical standpoint, this would mean: all notifications in a single extenderitem? or, would be nice to do a reimplementation of an extendergroup with scrolling members, the problem is that members are actually children of the extender, so no real relations between items and their group. this could suggest a change in how extenders work, so actually putting extenderitems in sublayouts of the extendergroups. not sure if would be actually a good things but would make possible groups of groups, ugly but at least the api wouldn't lie anymore. opinions? comments? would like to hear some feedback before implementing anything since each solution would lead to a different total screwing of the current implementation :p Cheers, Marco Martin ___ 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: notifications, again :D
I like it too and also prefer vertical but I wonder if showing only one
notification at a time wouldn't make user to lose important notifications,
like if (s)he just quickly glances at the first one, with no enough time for
the scroll, and clicks the X and dismisses them all.
No suggestion yet for avoiding this, though (just bringing the feedback). =/
But I think that's the way to go.
--
J (|´:¬{)»
-
Eu sou a ressurreição e a vida. Quem crê em mim, ainda que morra, viverá; e
todo o que vive e crê em mim não morrerá, eternamente. Crês isto?
O Senhor, Jesus Cristo - Jo.11:25-26
-
2010/1/25 Lukas Appelhans l.appelh...@gmx.de
Hey!
+1 on that... having tons of notifications showing up at the same time is
really distracting...
I'd go with some vertical scrolling, but make sure the timeout time gets
applied to each item when it is showing, not only when it's in the list...
:)
Lukas
Am Montag 25 Januar 2010 13:20:56 schrieb Marco Martin:
howdy all,
so, based on both ersonal experience and feedbacks i'm of course stilkl
not
happy on how notifications work, that's the pretty hard question of being
informative enough, vs not entirely cover the screen.
last thing i was thinking about was something that resembles rssnow:
http://imagebin.ca/view/fiFONCc.html
this would resemble the pattern of the appletbrowser, search and launch
and
possibly other stuff in the future.
-only one notification is shown at a time
-still valid notifications scrolls automatically or after arrows press,
like rssnow
bottom arrow would switch from valid to recent expired notifications
other options would be:
-something similar but with vertical scrolling
-leave as is now, but just displaying 2-3 otifications at a time,
throwing
away everything older (simpler ui, but loses significant informations)
now, for the technical standpoint, this would mean:
all notifications in a single extenderitem?
or, would be nice to do a reimplementation of an extendergroup with
scrolling members, the problem is that members are actually children of
the extender, so no real relations between items and their group.
this could suggest a change in how extenders work, so actually putting
extenderitems in sublayouts of the extendergroups. not sure if would be
actually a good things but would make possible groups of groups, ugly but
at least the api wouldn't lie anymore.
opinions? comments?
would like to hear some feedback before implementing anything since each
solution would lead to a different total screwing of the current
implementation :p
Cheers,
Marco Martin
___
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
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notifications, again :D
On Monday 25 January 2010, J Janz wrote: I like it too and also prefer vertical but I wonder if showing only one notification at a time wouldn't make user to lose important notifications, like if (s)he just quickly glances at the first one, with no enough time for the scroll, and clicks the X and dismisses them all. well, x would have to dismiss only one in this case (no idea how to do a dismiss all button that is not dangerous) about the verticl vs horizontal, if the popup will be wider than tall, a vertical scroll would become quite broken, while an horizontal one would give more the idea of scrolling trough pages Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notifications, again :D
last thing i was thinking about was something that resembles rssnow: http://imagebin.ca/view/fiFONCc.html It /looks/ like a nice idea but whether it really is is hard to tell. The problem I see with it is that it complicates the interaction even more than it is now. We really need Seele for this :) Cheerio -- Those people who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notifications, again :D
2010/1/25 Marco Martin notm...@gmail.com
well, x would have to dismiss only one in this case (no idea how to do a
dismiss all button that is not dangerous)
I don't see much of a problem with that. If the messages are still valid, so
the user should really see them and dismiss the ones he wants to (otherwise,
there's no reason for the message still be considered valid).
Is a dismiss all button really needed? At the moment, I think well weighted
valid messages would leave us with a reasonable amount of messages to
interact to.
about the verticl vs horizontal, if the popup will be wider than tall, a
vertical scroll would become quite broken, while an horizontal one would
give
more the idea of scrolling trough pages
However, as notifications grow up and shrink down (to a horizontal panel, at
least), it might feel more natural to have them scrolling up and down (like
all of them getting stacked after showing up). Well, also, if they come and
go horizontally in a vertical panel (I never tested and have no kde around
right now), they should scroll horizontally for that case. That is, IMHO,
it's more natural if they scroll in the same direction they show up and go
away.
--
J (|´:¬{)»
-
Eu sou a ressurreição e a vida. Quem crê em mim, ainda que morra, viverá; e
todo o que vive e crê em mim não morrerá, eternamente. Crês isto?
O Senhor, Jesus Cristo - Jo.11:25-26
-
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Subject: Re: On Plasmate's recent project list
On Mon, Jan 25, 2010 at 11:36 AM, Yuen Hoe Lim yuenho...@gmail.com wrote: There is also another problem and it still can get sticky :) When importing a 'project group' tarball, what happens when there are project folders with the same name in the target drive? It doesn't make sense to force an overwrite, so we'll need to seamlessly IMO, the import/export tarball feature will be used only for backup and restore purposes. In that case, forcing an overwrite *will* make sense, and that is what I originally meant. We aren't aiming for a per-project export feature. Think of it as 'Backup All Projects' and 'Restore All Projects'. I hope I'm able to explain what I originally meant. Cheers, rename the folders underneath (the user isn't aware of project folder names, so we can name them whatever we want as long as it avoids conflict). Now, renaming the folder will have implications for the git repository right...? Or am I just being overparanoid again :) Jason moofang Lim Yuen Hoe http://yuenhoe.co.cc/ On Sun, Jan 24, 2010 at 9:58 PM, Shantanu Tushar Jha jhahon...@gmail.comwrote: On 1/24/10, Yuen Hoe Lim yuenho...@gmail.com wrote: Uhm I dont get your concern; if you tar all the plasmate project directory for example, and then untar it, you also tar each git project history (because every project has its own local git repo). Thus, when untar-ing, you'll get both your projetc files and git repo for free :) Really? That's why I said I don't know much about git. So the git local repository is wholly contained in the folders themselves? That'll make things a lot simpler. Does that also mean that if I just delete the project folder the git repository goes down with it? :) Yep, even I was wondering why you were saying that. The whole git repo info, the packs etc are there in .git. So, AFAIK, just saving the contents will do. I can implement this backup-n-restore thing once you're done with the More Projects option :) yes sir ! xD Jason moofang Lim Yuen Hoe http://yuenhoe.co.cc/ -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ 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 -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add simple Type-and-Select feature to Folderview applet
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2659/ --- (Updated 2010-01-25 15:51:08.463465) Review request for Plasma, Fredrik Höglund and Celeste Lyn Paul. Changes --- seele, your help is needed here to figure out what should be the expected behaviour for the type-and-select for folderview applet. The details have been discussed on the reviewboard page. Kindly take a look at the behaviour and what are your recommendations. Thanks :) Summary --- This patch intends to provide a simple selection method to select icons. Its intended to be able to select a file plasma-desktop.desktop by just typing initial characters, plas for example. Comments on the hard-coded 2000ms welcome. If the user doesn't press any key within 2000ms after the last key press, the match string clears. This addresses bug 187241. https://bugs.kde.org/show_bug.cgi?id=187241 Diffs - trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.h 1078728 trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp 1078728 Diff: http://reviewboard.kde.org/r/2659/diff Testing --- Works with the latest trunk. Thanks, Shantanu ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Subject: Re: On Plasmate's recent project list
IMO, the import/export tarball feature will be used only for backup and restore purposes. In that case, forcing an overwrite *will* make sense, and that is what I originally meant. We aren't aiming for a per-project export feature. Think of it as 'Backup All Projects' and 'Restore All Projects'. I hope I'm able to explain what I originally meant. I understood what you originally meant, but why restrict it so? I don't personally think it's great to force overwrite and I don't think a conflict scenario is all too unlikely - 'Backup All Projects' means I'm saving all current my work and bringing it with me. There is no guarantee that I won't create some projects and import a couple more in my new location before I decide to bring in my old work. You can say that the 'correct' way to backup all and restore all is to do the restore first thing, but users will do what they want - and then complain when they have a problem. And no matter how rare a conflict scenario is, forcing overwrite is serious business. We're talking about forcing the user to choose between losing whole existing projects, and not being able to import groups of projects. Either choice could mean losing contact with a lot of the user's previous work. Also not forgetting that folder names are not exposed to the user, so folder name conflicts are not visible to the user, and he will probably be quite bewildered if we suddenly pop up and say hey you have a conflict! when he sees none. IMO we should avoid force-overwrite if we can at all, and if Diego is right (he probably is :P ) then it's pretty trivial to just get PlasMate to do some under-the-hood renaming and circumvent all the possible problems. Jason moofang Lim Yuen Hoe http://yuenhoe.co.cc/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Subject: Re: Subject: Re: On Plasmate's recent project list
-- Messaggio inoltrato -- From: Yuen Hoe Lim yuenho...@gmail.com To: plasma-devel@kde.org Date: Tue, 26 Jan 2010 00:11:17 +0800 Subject: Re: Subject: Re: On Plasmate's recent project list IMO, the import/export tarball feature will be used only for backup and restore purposes. In that case, forcing an overwrite *will* make sense, and that is what I originally meant. We aren't aiming for a per-project export feature. Think of it as 'Backup All Projects' and 'Restore All Projects'. I hope I'm able to explain what I originally meant. I understood what you originally meant, but why restrict it so? I don't personally think it's great to force overwrite and I don't think a conflict scenario is all too unlikely - 'Backup All Projects' means I'm saving all current my work and bringing it with me. And there is even more, in my opinion. When the number of projects becomes relevant, the user could forget how he/she properly named each of them, thus it's easy to create a new project with a name already assigned. So a conflict scenario is more plausible. ( I'm wondering if could be cool to implement a bacukp support over gitorious, when my backend will be available :) There is no guarantee that I won't create some projects and import a couple more in my new location before I decide to bring in my old work. You can say that the 'correct' way to backup all and restore all is to do the restore first thing, but users will do what they want - and then complain when they have a problem. And no matter how rare a conflict scenario is, forcing overwrite is serious business. We're talking about forcing the user to choose between losing whole existing projects, and not being able to import groups of projects. I totally agree. We have to keep in mind that our target are beginner/intermediate developers, thus we have to ease their development cycle without forcing them on such drastic choices. By the way, we should also add a Remove project button or whatever because, in order to test python/ruby/js plasmoid/dataengine/runner, I created a lot of projects that are no longer needed; so we need a button to do some spring-cleaning IMO :) Either choice could mean losing contact with a lot of the user's previous work. Also not forgetting that folder names are not exposed to the user, so folder name conflicts are not visible to the user, and he will probably be quite bewildered if we suddenly pop up and say hey you have a conflict! when he sees none. IMO we should avoid force-overwrite if we can at all, and if Diego is right (he probably is :P ) then it's pretty trivial to just get PlasMate to do some under-the-hood renaming and circumvent all the possible problems. Jason moofang Lim Yuen Hoe http://yuenhoe.co.cc/ ___ 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: notifications, again :D
On January 25, 2010 04:20:56 Marco Martin wrote: howdy all, so, based on both ersonal experience and feedbacks i'm of course stilkl not happy on how notifications work, that's the pretty hard question of being informative enough, vs not entirely cover the screen. last thing i was thinking about was something that resembles rssnow: http://imagebin.ca/view/fiFONCc.html this would resemble the pattern of the appletbrowser, search and launch and possibly other stuff in the future. -only one notification is shown at a time -still valid notifications scrolls automatically or after arrows press, like rssnow bottom arrow would switch from valid to recent expired notifications ebbeh... three arrows? my first impression is eek! different! scrolling! scary! ;) I kinda feel like this is just hiding the problems instead of really solving them. so.. stepping back for a minute, here's what actually causes me trouble with the current notifications: -they cover a rather useful chunk of my screen. I guess I could solve that myself by putting my systray in a less convenient place. -they cover too much of my screen. I think there's a lot that could be done to save space before showing only one at a time. those two extenders for completed vs. incomplete take a big chunk all by themselves, even when they have nothing under them. -they're not easy to dismiss. I did try to hit the little X last time, but the stack of notifications went away just as I was clicking the mouse and I hit something in kmail instead. I really really miss the click anywhere (other than a button) to dismiss behaviour. -they cover it for too long. something that especially bugs me is that when the latest notification itself goes away, the rest of the stack (even if it's just those two category headers) hangs around for an extra few seconds, and because of that my panel is also staying visible for those extra few seconds. I just want the darn thing to go *away*. -a lot of notifications shouldn't be there to begin with. I really don't care that ksnapshot is downloading my last screenshot over sftp when I run it. I don't need that completed download hanging around for minutes adding to the size of my notification area. perhaps this is ksnapshot's fault, but still, improvements could be made in what not to show. or at least what not to keep around once it's done. the same sort of thing happens if I open a link in gwenview or okular or something. on the one hand it's nice to know that something is happening; on the other hand if it's just a little 20k image it'll be done in under a second and then I'll have that completed download clogging up the notification area for much longer. so... showing only one at a time would solve the covers too much of my screen problem, which in turn would make me not care so much about the rest of the problems... it might introduce other potential issues too though. like the (probably small) chance of a low-battery warning being missed because something starts downloading a file half a second later. hmm. it could make sense to show only the most recent in the popup (and have a minimum display time of a couple of seconds perhaps?). I don't like the idea of clicking arrows to show them one by one, though. I feel half-blind when I can only see the current item in a list and don't know how many items there are or where I am. I'd suggest rethinking how all the other notifications are shown. show the one most recent, yes, but perhaps have a button to expand and show all the recent/in-progress notifications. and another small button somewhere to show a log of old/completed notiiciations, in a separate window. more like a log viewer - yes, we haven't actually implemented logging of the notifications yet, but it'd be a place to put them when we do. and some things, like those ksnapshot and gwenview downloads, maybe they shouldn't be logged... but if they immediately went to that log viewer when they're done instead of hanging around on screen then I wouldn't care so much. -- 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: notifications, again :D
On Monday 25 January 2010, Chani wrote: On January 25, 2010 04:20:56 Marco Martin wrote: howdy all, so, based on both ersonal experience and feedbacks i'm of course stilkl not happy on how notifications work, that's the pretty hard question of being informative enough, vs not entirely cover the screen. last thing i was thinking about was something that resembles rssnow: http://imagebin.ca/view/fiFONCc.html this would resemble the pattern of the appletbrowser, search and launch and possibly other stuff in the future. -only one notification is shown at a time -still valid notifications scrolls automatically or after arrows press, like rssnow bottom arrow would switch from valid to recent expired notifications ebbeh... three arrows? my first impression is eek! different! scrolling! scary! ;) I kinda feel like this is just hiding the problems instead of really solving them. yes, 3 arrows is defnitely too much so.. stepping back for a minute, here's what actually causes me trouble with the current notifications: -they cover a rather useful chunk of my screen. I guess I could solve that myself by putting my systray in a less convenient place. is that chunk way more mportant than the others? i guess so since tends to be where kmail message bodies are... they could popup in a different are of the screen when they are automatic and still pop up there when explicitly open... fear would be even more confusing tough -they cover too much of my screen. I think there's a lot that could be done to save space before showing only one at a time. those two extenders for completed vs. incomplete take a big chunk all by themselves, even when they have nothing under them. yes. some of those should be removed, maybe i have half an idea how to do that will explain later... but i think i'm still thinking about scrolling... -they're not easy to dismiss. I did try to hit the little X last time, but the stack of notifications went away just as I was clicking the mouse and I hit something in kmail instead. I really really miss the click anywhere (other than a button) to dismiss behaviour. probably would be easy to do... is what we want? maybe one wants to click a button misses it, the notification goes away and thinks having actually managed to press that button -they cover it for too long. something that especially bugs me is that when the latest notification itself goes away, the rest of the stack (even if it's just those two category headers) hangs around for an extra few seconds, and because of that my panel is also staying visible for those extra few seconds. I just want the darn thing to go *away*. yes, they should have a max, right now a notification can ask to be immortal, kopete ones are iirc (that's in the ugly spec) -a lot of notifications shouldn't be there to begin with. I really don't care that ksnapshot is downloading my last screenshot over sftp when I run it. I don't need that completed download hanging around for minutes adding to the size of my notification area. perhaps this is ksnapshot's fault, but still, improvements could be made in what not to show. or at least what not to keep around once it's done. the same sort of thing happens if I open a link in gwenview or okular or something. on the one hand it's nice to know that something is happening; on the other hand if it's just a little 20k image it'll be done in under a second and then I'll have that completed download clogging up the notification area for much longer. yes, many are useless but not much we can do about it. for jobs the problem is totally different, in that case we exclude ones that last less than 2 seconds, but even this way useless one go in. i aso think completed ones should become the same widget of notification, so living in the same extender with the same lifespan and go in the same old notifications pool. so... showing only one at a time would solve the covers too much of my screen problem, which in turn would make me not care so much about the rest of the problems... it might introduce other potential issues too though. like the (probably small) chance of a low-battery warning being missed because something starts downloading a file half a second later. job progress would still be in a different zone... or shouldn't they? hmmm i think jobs should remain the more visible as possible, we have already bug reports about people thingking jobs are done because the popup auto hidden... hmm. it could make sense to show only the most recent in the popup (and have a minimum display time of a couple of seconds perhaps?). I don't like the idea of clicking arrows to show them one by one, though. I feel half-blind when I can only see the current item in a list and don't know how many items there are or where I am. I'd suggest rethinking how all the other notifications are shown. show the one most recent, yes, but perhaps have a button to
Re: notifications, again :D
On January 25, 2010 12:23:29 Marco Martin wrote: On Monday 25 January 2010, Chani wrote: On January 25, 2010 04:20:56 Marco Martin wrote: howdy all, so, based on both ersonal experience and feedbacks i'm of course stilkl not happy on how notifications work, that's the pretty hard question of being informative enough, vs not entirely cover the screen. last thing i was thinking about was something that resembles rssnow: http://imagebin.ca/view/fiFONCc.html this would resemble the pattern of the appletbrowser, search and launch and possibly other stuff in the future. -only one notification is shown at a time -still valid notifications scrolls automatically or after arrows press, like rssnow bottom arrow would switch from valid to recent expired notifications ebbeh... three arrows? my first impression is eek! different! scrolling! scary! ;) I kinda feel like this is just hiding the problems instead of really solving them. yes, 3 arrows is defnitely too much so.. stepping back for a minute, here's what actually causes me trouble with the current notifications: -they cover a rather useful chunk of my screen. I guess I could solve that myself by putting my systray in a less convenient place. is that chunk way more mportant than the others? i guess so since tends to be where kmail message bodies are... they could popup in a different are of the screen when they are automatic and still pop up there when explicitly open... fear would be even more confusing tough my systray is on a hidden panel at the top center of my screen. it's a great place for kmix and klipper (right beside my taskbar and battery plasmoid) but not so great for notifications if I'm reading a web page or something. works well for konsole, though, since the important stuff is at the bottom there. :) there's really no perfect way to solve that, I suppose. it's just slightly inconvenient sometimes that systray and notifications are bound together. probably not worth doing anything about until we're free of the old systray stuff. -they cover too much of my screen. I think there's a lot that could be done to save space before showing only one at a time. those two extenders for completed vs. incomplete take a big chunk all by themselves, even when they have nothing under them. yes. some of those should be removed, maybe i have half an idea how to do that will explain later... but i think i'm still thinking about scrolling... -they're not easy to dismiss. I did try to hit the little X last time, but the stack of notifications went away just as I was clicking the mouse and I hit something in kmail instead. I really really miss the click anywhere (other than a button) to dismiss behaviour. probably would be easy to do... is what we want? maybe one wants to click a button misses it, the notification goes away and thinks having actually managed to press that button I'm not sure. I haven't heard anything from anyone else about this behaviour. but if you miss a button you're probably going to notice that whatever the button was supposed to do didn't happen... the only case where it'd suck would be when you're trying to hit the don't shut down my computer yet! button. I almost wish there was a global keyboard shortcut for dismiss all notifications. but that seems like overkill. -they cover it for too long. something that especially bugs me is that when the latest notification itself goes away, the rest of the stack (even if it's just those two category headers) hangs around for an extra few seconds, and because of that my panel is also staying visible for those extra few seconds. I just want the darn thing to go *away*. yes, they should have a max, right now a notification can ask to be immortal, kopete ones are iirc (that's in the ugly spec) that too, although that's not what I was talking about. the notifications go away and the notification-area is still there taking up screen space. it drives me nuts. -a lot of notifications shouldn't be there to begin with. I really don't care that ksnapshot is downloading my last screenshot over sftp when I run it. I don't need that completed download hanging around for minutes adding to the size of my notification area. perhaps this is ksnapshot's fault, but still, improvements could be made in what not to show. or at least what not to keep around once it's done. the same sort of thing happens if I open a link in gwenview or okular or something. on the one hand it's nice to know that something is happening; on the other hand if it's just a little 20k image it'll be done in under a second and then I'll have that completed download clogging up the notification area for much longer. yes, many are useless but not much we can do about it. there must be something *someone* can do about it. educate developers on how to make internal jobs not show
Re: notifications, again :D
On January 25, 2010, Chani wrote: how can we tell the difference between these jobs and treat them appropriately? applications mark them as such. it's part of the KIO/KJob API. -- 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: QCompleter on Plasma::LineEdit not working properly
On Thursday 21 January 2010 22:07:21 Aaron J. Seigo wrote: On January 21, 2010, Cyrill Helg wrote: On Tuesday 19 January 2010 21:42:23 Aaron J. Seigo wrote: On January 19, 2010, Cyrill Helg wrote: I just upgraded qt to v. 4.6.1 and rebuilt my plasmoid, but I'm still facing the same issues. ok, good since that matches what we've (or rather, Marco) have also found. it seems the bug is still there and needs to be found and fixed. let's see what we can do . Okai, let me know if there is anything to test. (At the moment the typing does not stuck any longer it just completes on only the first character). Regards Cyrill ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notifications, again :D
On January 25, 2010, Marco Martin wrote: -only one notification is shown at a time -still valid notifications scrolls automatically or after arrows press, like rssnow bottom arrow would switch from valid to recent expired notifications i like the idea of one notification at a time as well as being able to scroll through them. there are some other design parameters here, too: * what is shown automatically (popped up) as opposed to when the user clicks on the icon * how are jobs displayed * how are notifications from multiple apps shown when a notification first appears, right now it pops up along with everything else that is also there. that's not particularly great for two reasons: a) i've probably already seen the other information already, so it becomes an unintentional nagging b) it makes it harder to pick out what the new content is amongst all that old content so i think it would make sense to have a what pops up UI, and one-at-a-time, scrolling one after the other if there are lots of them makes sense to me. if there are lots of them, clicking the close button or the (i) icon should dismiss the popup UI until new ones appear. when clicking the (i) icon, i'd like to be able to see the last active notification of each application. e.g. if kopete and kontact have both sent out a notification to me, i should be able to see both if i purposefully click the (i). however, if kopete has sent 10 notifications, i should probably only see the most recent one, and be able to scroll through the older ones. so perhaps there is a notification scroller widget? it can be used to display all new notifications as they appear in the same scroller (regardless of whether they come from different applications). it can also be used to show all the notifications of any one application when the (i) is clicked. an expand button in the auto-popup widget could expand to show the full interface, which would therefore be synonymous with clicking the (i) when the notifications UI closed. but what about jobs? perhaps a similar mechanism but with some tweaks. the summary view could be *in* the jobs tracker area instead of a separate item. the jobs tracker could expand/contract to show all the jobs and the user could page between them using the same scroller window? or perhaps it could expand to show each active job as a one-liner: filename [--- progress bar ] and each of those could also be expanded to show the full informational widget we have now. by default it would show each download as a one-liner, and this could be minimized down to show just the summary. the remaining use case there would be someone who wants to see all jobs fully expanded by default. in any case, this would mean that the jobs area would only ever take one section of the notifications UI, and each application would get at most one section of its own as well. when a job starts or a new notification appears, the new things scroller appears and shows JUST the new items and autohides after a while unless the user expands it to show the full display. in fact, if we wanted, we could make the full display collapasable so that it only shows the new things UI. in the code, i think these would probably end up as two different widgets totally, but to the user it could appear that it's the same widget (because it appears in the same location with similar information in it) just expanding/shrinking in detail and size. this would make it a drill-down type interface which shows more information at once when the user requests it. as for positioning ... maybe now that we can turn everything else on/off in the system tray it's time to add a feature so that it is also able to be disabled in a given tray. in fact, maybe it's time it became it's own plasmoid altogether which is by default hosted in the system tray. -- 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: notifications, again :D
On Monday 25 January 2010, Aaron J. Seigo wrote: On January 25, 2010, Marco Martin wrote: -only one notification is shown at a time -still valid notifications scrolls automatically or after arrows press, like rssnow bottom arrow would switch from valid to recent expired notifications i like the idea of one notification at a time as well as being able to scroll through them. there are some other design parameters here, too: * what is shown automatically (popped up) as opposed to when the user clicks on the icon wonder if it's better to just expand the same popup dialog or creating a totally different one... i was thinking about just giving a different default height from the scroller, like tall just enough to show one vs enogh to show 2 or 3 that makes me pose a question... will we still use extenderitems for notifications? seemed a cool ideea to be able to put them on the desktop.. in practice didn't find it sooo useful at the moment i'm trying to reparent extenderitems in a scrollwidget. it seems to work quite well even if if it still have some funny behaviour.. (and it comes again on having extendergroup members actually belog to the extendergroup rather than it is now) * how are jobs displayed * how are notifications from multiple apps shown when a notification first appears, right now it pops up along with everything else that is also there. that's not particularly great for two reasons: a) i've probably already seen the other information already, so it becomes an unintentional nagging b) it makes it harder to pick out what the new content is amongst all that old content so when a notification pops up just show the notification, not jobs? so i think it would make sense to have a what pops up UI, and one-at-a-time, scrolling one after the other if there are lots of them makes sense to me. if there are lots of them, clicking the close button or the (i) icon should dismiss the popup UI until new ones appear. [...] as for positioning ... maybe now that we can turn everything else on/off in the system tray it's time to add a feature so that it is also able to be disabled in a given tray. well, actually is already posible to enable/disable notifications and jobs per-systray in fact, maybe it's time it became it's own plasmoid altogether which is by default hosted in the system tray. yes, probably. i fear the extraction could be quite painful however :D Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notifications, again :D
On January 25, 2010, Marco Martin wrote: On Monday 25 January 2010, Aaron J. Seigo wrote: On January 25, 2010, Marco Martin wrote: -only one notification is shown at a time -still valid notifications scrolls automatically or after arrows press, like rssnow bottom arrow would switch from valid to recent expired notifications i like the idea of one notification at a time as well as being able to scroll through them. there are some other design parameters here, too: * what is shown automatically (popped up) as opposed to when the user clicks on the icon wonder if it's better to just expand the same popup dialog or creating a totally different one... i was thinking about just giving a different default height from the scroller, like tall just enough to show one vs enogh to show 2 or 3 at least personally, i don't want to see the same content in those two views. when a notification first happens, i want to just see it. but when i want to see a specific notification, i would like to be able to quickly see what a specific application has said. the use case is when kopete is busy spamming me and then something i actually DO care about appears. when i pop open the notifications area, i want to be able to prevent kopete from getting in my way of other notifications. ah, which brings us to another interesting one: what happens when a critical notification like power status comes in? i think that critical notifications should pre-empt all other notifications in the auto-popup until they are dealt with. so if a power management notification happens, kopete notifications are silently queued up _behind_ that notification until it the critical notification is dealt with. (a second stream of notifications, one for critical ones and one for everything else is a possibility, but i'm not sure it's needed?) that makes me pose a question... will we still use extenderitems for notifications? i don't think it's a requirement, really; the entire notification area could be an extender, or the notifications versus the jobs, perhaps. or perhaps each scroller could be an extender (meaning that each app would get an extender for its notifications, and the jobs would get one to share). but if they weren't extenders, nobody would die :) as for positioning ... maybe now that we can turn everything else on/off in the system tray it's time to add a feature so that it is also able to be disabled in a given tray. well, actually is already posible to enable/disable notifications and jobs per-systray in fact, maybe it's time it became it's own plasmoid altogether which is by default hosted in the system tray. yes, probably. i fear the extraction could be quite painful however :D now that Applets can advertise their status and the logic is wrapped in a DataEngine, it really shouldn't be too difficult to manage. it would mean that some special casing for the information widget would be removed in the system tray, but that can only be a good thing and force us to find better ways of handling that if needed. everything is pretty well encapsulated / separated in the system tray, so extraction into a PopupApplet shouldn't be too hard. -- 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: Bookmarks plasmoid moved to kdereview
On January 24, 2010, Friedrich W. H. Kossebau wrote: Upcoming Tuesday two weeks have passed since the move into kdereview. Thanks to Albert, Burkhard and Laurent some i18n problems have been fixed. Did anyone else have the time to give this plasmoid a small test? yes, i looked through the code today as well as used it. very nice :) my only suggestions are: * in the tooltip, if a subfolder is selected maybe add that it's a bookmarks folder? right now that information gets lost when a subfolder is selected * in the configuration dialog, instead of having a button that opens a dialog that lists the folders available it would be nice to have the tree right there. right now there is only KBookmarksDialog, of course, which makes this approach necessary, at least without tons of duplicated code. a KBookmarksTree (which KBookmarksDialog would use internally) would be a nice addition to the kbookmarks library and would make the applet's config dialog much nicer imho. it shouldn't be _too_ difficult since KBookmarksDialog already has an implementation of such a tree internally. neither are big issues, and i don't think the KBookmarksDialog is a blocker at all (more of a would be nice) to including this applet in kdeplasma-addons. please move it over at your leisure :) -- 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: Subject: Re: On Plasmate's recent project list
By the way, we should also add a Remove project button or whatever because, in order to test python/ruby/js plasmoid/dataengine/runner, I created a lot of projects that are no longer needed; so we need a button to do some spring-cleaning IMO :) Yeah I was planning to add that, that's why I was asking if all we needed to do to kill a project + git repo is to delete the whole folder :) You probably already know this, but in the meantime you could just kill all the stuff in ~/.kde4/share/apps/plasmate/ and kill the config files in ~/.kde4/share/config/plasmate* to start with a clean slate again :) Jason moofang Lim Yuen Hoe http://yuenhoe.co.cc/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Imgur support in Pastebin applet
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2324/ --- (Updated 2010-01-26 04:29:10.863809) Review request for Plasma. Summary --- A patch to add support for uploading images to imgur.com for the Pastebin applet. Diffs (updated) - trunk/KDE/kdeplasma-addons/applets/pastebin/pastebin.h 1079836 trunk/KDE/kdeplasma-addons/applets/pastebin/pastebin.cpp 1079836 trunk/KDE/kdeplasma-addons/applets/pastebin/pastebinConfig.ui 1079836 trunk/KDE/kdeplasma-addons/dataengines/pastebin/CMakeLists.txt 1079836 trunk/KDE/kdeplasma-addons/dataengines/pastebin/backends/backends.h 1079836 trunk/KDE/kdeplasma-addons/dataengines/pastebin/backends/imgur.h PRE-CREATION trunk/KDE/kdeplasma-addons/dataengines/pastebin/backends/imgur.cpp PRE-CREATION trunk/KDE/kdeplasma-addons/dataengines/pastebin/pastebinservice.h 1079836 trunk/KDE/kdeplasma-addons/dataengines/pastebin/pastebinservice.cpp 1079836 Diff: http://reviewboard.kde.org/r/2324/diff Testing --- Tried on current trunk, works fine. Thanks, Nikhil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Subject: Re: Subject: Re: On Plasmate's recent project list
On Mon, Jan 25, 2010 at 10:44 PM, Diego Casella ([Po]lentino) polentino...@gmail.com wrote: -- Messaggio inoltrato -- From: Yuen Hoe Lim yuenho...@gmail.com To: plasma-devel@kde.org Date: Tue, 26 Jan 2010 00:11:17 +0800 Subject: Re: Subject: Re: On Plasmate's recent project list IMO, the import/export tarball feature will be used only for backup and restore purposes. In that case, forcing an overwrite *will* make sense, and that is what I originally meant. We aren't aiming for a per-project export feature. Think of it as 'Backup All Projects' and 'Restore All Projects'. I hope I'm able to explain what I originally meant. I understood what you originally meant, but why restrict it so? I don't personally think it's great to force overwrite and I don't think a conflict scenario is all too unlikely - 'Backup All Projects' means I'm saving all current my work and bringing it with me. And there is even more, in my opinion. When the number of projects becomes relevant, the user could forget how he/she properly named each of them, thus it's easy to create a new project with a name already assigned. So a conflict scenario is more plausible. ( I'm wondering if could be cool to implement a bacukp support over gitorious, when my backend will be available :) Oh yes, then we have to have a conflict resolution method anyway. There is no guarantee that I won't create some projects and import a couple more in my new location before I decide to bring in my old work. You can say that the 'correct' way to backup all and restore all is to do the restore first thing, but users will do what they want - and then complain when they have a problem. And no matter how rare a conflict scenario is, forcing overwrite is serious business. We're talking about forcing the user to choose between losing whole existing projects, and not being able to import groups of projects. I totally agree. We have to keep in mind that our target are beginner/intermediate developers, thus we have to ease their development cycle without forcing them on such drastic choices. By the way, we should also add a Remove project button or whatever because, in order to test python/ruby/js plasmoid/dataengine/runner, I created a lot of projects that are no longer needed; so we need a button to do some spring-cleaning IMO :) Either choice could mean losing contact with a lot of the user's previous work. Also not forgetting that folder names are not exposed to the user, so folder name conflicts are not visible to the user, and he will probably be quite bewildered if we suddenly pop up and say hey you have a conflict! when he sees none. IMO we should avoid force-overwrite if we can at all, and if Diego is right (he probably is :P ) then it's pretty trivial to just get PlasMate to do some under-the-hood renaming and circumvent all the possible problems. Ok, then lets design some generic method for this. When someone gets an outline of a method, mail to the list and we can discuss. :) Jason moofang Lim Yuen Hoe http://yuenhoe.co.cc/ ___ 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 -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Subject: Re: Subject: Re: On Plasmate's recent project list
-- Messaggio inoltrato -- From: Yuen Hoe Lim yuenho...@gmail.com To: plasma-devel@kde.org Date: Tue, 26 Jan 2010 13:16:50 +0800 Subject: Re: Subject: Re: On Plasmate's recent project list By the way, we should also add a Remove project button or whatever because, in order to test python/ruby/js plasmoid/dataengine/runner, I created a lot of projects that are no longer needed; so we need a button to do some spring-cleaning IMO :) Yeah I was planning to add that, that's why I was asking if all we needed to do to kill a project + git repo is to delete the whole folder :) You probably already know this, but in the meantime you could just kill all the stuff in ~/.kde4/share/apps/plasmate/ and kill the config files in ~/.kde4/share/config/plasmate* to start with a clean slate again :) Yep, that's why I need something more easy to accomplish that :) Jason moofang Lim Yuen Hoe http://yuenhoe.co.cc/ From: Shantanu Tushar Jha jhahon...@gmail.com And there is even more, in my opinion. When the number of projects becomes relevant, the user could forget how he/she properly named each of them, thus it's easy to create a new project with a name already assigned. So a conflict scenario is more plausible. ( I'm wondering if could be cool to implement a bacukp support over gitorious, when my backend will be available :) Oh yes, then we have to have a conflict resolution method anyway. Of course we have :) The coolness I was talking is about having version controlled backup system over gitorious, so you can access it from every pc with an internet connection, without worrying about in what folder/pendrive/external drive you put it before formatting the pc. One click, and you backup all your projects online; an other click ( + cool anti-conflict method ), and you'll get them back :) Either choice could mean losing contact with a lot of the user's previous work. Also not forgetting that folder names are not exposed to the user, so folder name conflicts are not visible to the user, and he will probably be quite bewildered if we suddenly pop up and say hey you have a conflict! when he sees none. IMO we should avoid force-overwrite if we can at all, and if Diego is right (he probably is :P ) then it's pretty trivial to just get PlasMate to do some under-the-hood renaming and circumvent all the possible problems. Ok, then lets design some generic method for this. When someone gets an outline of a method, mail to the list and we can discuss. :) What about performing a sort of sha1sum for each project file, and use it to perform a check when restoring a backup ? So, if we find two identical packages names with different hashes, we could prompt a dialog with the name of the package with an overwrite checkbox and a details button to give more infos about the projects. ( That's reptty rough I know, so what about your opinion?) Well, I'm going to take my DC examinations, bye . Jason moofang Lim Yuen Hoe http://yuenhoe.co.cc/ ___ 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 -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ 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
