i spent some time outside in this unexpected brilliance.
i also spent some time working on ksnapshot in trunk and dolphin. tomorrow is a plasma day and i'll be back to regular blogging about that methinks. today was the day to write copious notes that draw together the last two years of thought on managing the kde brands and an open source marketing collective as well. productive, to say the least. it came at the expense of doing the housework i planned on doing today and the free hugs thing i expected to spend the first chinook doing. i blame the sunshine.
have i mentioned in my blog yet how kevin ottens came up with a great way to solve the issues with things like media:/ and remote:/ without getting rid of them? well, he did. using redirects we can deliver plain ol' standard URLs to apps and still keep the wonders of media:/ and what not in the file manager. best we can really abstract out a lot of complexity involved by using a combination of sensible bookmarks and the breadcrumb widget.
i'm quite excited about this .. amidst all the calls for removing those urls because they either messed up apps that are written by people who don't seem to grok kio or because they don't follow some industry spec out there i kept thinking that this would be throwing the baby out with the bath water. there are well documented use cases for these views of the computer and doing them via ioslaves allows us to quite easily provide for nice solutions without tons of ugly custom code for that.
something i would like to see is handling of a more sophisticated data type for visualizations that some of our ioslaves would return. for instance, there's the system information slave in suse which, while really cool, sucks more than it rightfully should because the options are pretty well limited to html since that gives them layout and interaction. would be nice to see svg based interaction views and select ioslaves that take advantage of that.
and on a final note, while working on ksnapshot i noticed how much faster kde4 apps seem to start up. so i measured it quickly in a very non-scientific manner and the difference is impressive. i was wondering if i was noticing things, but nope .. seems knsapshot starts up from a command line something like 2x faster in kde4. wow. now, perhaps there's more settings and cruft being loaded in my kde3 ksnapshot (as i said, this was not a scientific test) but then i've never noticed ksnapshot open that fast even on a "blank slate" account. neat. hopefully this trend persists through to the 4.0 release. or, as richard moore noted, this just means we have room for features that take one more second of start up time in ksnapshot ;)
if you're curious what i was doing with ksnapshot (and you shouldn't be, it's boring stuff ;):
an "open with" button feature had been committed but it opened up a dialog and had a number of oddnesses to it. so i quickly changed it to a button with a menu. next will be to add actions like "mail to" to the button, which really calls for servicemenus. but that means being able to query for more than just the mimetypes. it also really needs the long overdue upgrade of servicemenus to their own class that can be instantiated and used anywhere without duplicating code everywhere. i need to think a bit about what precise feature enhancements (and removal?) should happen there and how to achieve it. i haven't put an ounce of thought into it to this point beyond, "this needs some love".
14 comments:
Glad to hear that KDE4 apps are getting some nice speed improvements (not that KDE3 is slow). But is that Fluxbox in that screenshot? :)
Excellent move on the Open With function. Open With is almost always my next step anyway. Thx.
It is putting the image in /tmp somewhere or creates a ~/Pictures/snapshotx.png before handing it out to the editor?
Could you elaborate on how redirects would deal with media:/ and remote:/? I wasn't aware of this approach...
I thought there was a plan to remove all the "Mail to" shortcuts from KDE apps. IMHO it is sufficient to let the user save the picture, and then they can open an e-mail app and compose the message. The advantage of this is that the file will have non-random name, which will help the recipient figure out what the file is supposed to be.
Also, if there's going to be a "Mail to" button, why not a "IM to" and "IRC to" and "Skype to" button as well ;) There's just too many possibilities to list them all. I suggest sticking to the UNIX tradition of one function per application.
Justin: "But is that Fluxbox in that screenshot?"
no. that's plasma!
*pause*
*giggle* kidding of course. and no, it's not fluxbox, it's the real deal: blackbox. which is what i used to run before i switched to kde with kde 2.0.
i'm using it with my kde4 test user to try out individual apps.
@daniel: "It is putting the image in /tmp somewhere"
yes. but it deletes them on app closing. if we ever extend the resources concept to user things like pictures then perhaps we can get away from this.
@vladc6: 'Could you elaborate on how redirects would deal with media:/ and remote:/'
essentially when the user is actually viewing files they are access via file:/ or whatever the "most local" url is, which is never remote:/, etc... a redirect happens whenever an ioslave looks at a url and says, "oh, this is certainly a path i understand but i only know how to rewrite it to another url, which is --------". so remote://work server/home/aseigo might internally redirect to fish://aseigo@work.com/home/aseigo. the file manager can catch this redirect and reflect that in the UI, thereby never losing that remote:/ was used to access that listing while still passing "real" uri's to other apps. huzzah.
'I thought there was a plan to remove all the "Mail to" shortcuts from KDE apps.'
*shrug* people use this stuff. who am i to take it away. particularly if its run-time extensible via things like servicemenus?
'if there's going to be a "Mail to" button, why not a "IM to" and "IRC to" and "Skype to" button as well'
yes, it should probably be "send to" and you pick a destination address and then it decides from there what to do. something that works with the address book + personal accounts (via akonadi?) would probably be best.
The redirect idea sounds like a step in the right direction because it hides some connection parameters. But it doesn't yet solve the problem users encounter when they go the command line or a GNOME app and try to use that URL.
I don't think KSnapshot should list destination addresses, because quite often people are lazy and neglect to add their contacts to their "Address Book". Also, they may just want to to email someone for the first time. And what if they want to send it to more than one address?
I think it would be better to simply start a KMail "Compose" window with the screenshot already attached and with the To/CC/Subject fields left empty.
Also, the user should have the chance to give an intelligible name to the image file.
@vladc6: "But it doesn't yet solve the problem users encounter when they go the command line or a GNOME app and try to use that URL."
until the OS people get their head above water there's not much i think we can do about the command line issue. this means linux, bsd, solaris, mac, windows ..... and none of this stands in the way of these people.
the good news for the command line is that copying a file from the file manager to konsole will give you something that has a higher chance of being useful.
for gnome apps maybe we can eventually standardize the use of some of these urls. but i'm not overly concerned about people not being able to use the gnome file manager to get to remote:/foo. it would be awesome if they could but seeing the immense problems we have getting much more trivial things standardized i'd prefer not to see kde users punished for it by having lowest common denominator interfaces as their only choice.
ballancing innovation with interoperability is tricky.
'quite often people are lazy and neglect to add their contacts to their "Address Book".'
this is why i said "and their personal accounts" so if the person is not in their address book they can select their email or their jabber or their * account. =)
The KIOSlave stuff sounds so complicate it will probably never work, and even if it does, what's the benefit? What if we can now call fish:/ remote:/ ? Who needs more words? More words mean more misunderstanding. Why not just KISS?
hi aseigo,
On ksnapshoot, it could kill us if a video capture was put in (video capture seems to become fashion this times...).
How apt, a friend of mine just mentioned ksnapshot last night. Told him he should throw an e-mail in the general direction of you guys, maybe he did, I don’t know.
His idea was to have a snapshot mode which would create a… what should I call it… “WidgetShot”? Basically you have something scrollable (be it a mere KTextEdit or a Konqueror browser area), and ksnapshot would make a single image of the whole content of the scrollable, including everything from the very first line to the very last.
I told him that’s probably not quite possible. He said there are software on Windows which can do it. I’ve certainly never seen anything here on Linux (neither KDE, let alone GNOME) that was able to do that.
A resize option to some standard sizes:
like 600x800, 1024x1280, etc
would be nice to have.
@Gato: "The KIOSlave stuff sounds so complicate it will probably never work,"
well, it's working here and i'm doing usability testing to ensure that it also works for the general public =)
" and even if it does, what's the benefit? What if we can now call fish:/ remote:/ ?"
remote:/ gives access to samba/cifs shares, zeroconf, ssh, ftp and more networks. some is autodiscoverable (samba, zeroconf) and some requires the user to bookmark them.
so remote is much more than ssh.
what the user sees, however, is just the word "Network". remote:/ is a technical detail, but an important one since it gives us the chance of handling all this rather transparently to both the application developer as well as the user.
@johann: "video capture was put in"
that would be very cool indeed. though perhaps it best left to another application? i'm waiting to see how the couple of kde screen video apps that in development right now turn out
Thanks for your responses, Aaron!
i'd prefer not to see kde users punished for it by having lowest common denominator interfaces as their only choice.
I agree, but with a KIO-FUSE and XATTR solution, KDE users get to keep absolutely all of KDE's file IO capabilities while providing legacy IO compatibility to non-KDE apps.
The KIO-FUSE and XATTR proposal is basically the same thing as the "redirects" you mentioned except that the redirects are stored in the file's XATTR fields.
Also, Kevin Ottens' redirects proposal has drawbacks for pure KDE users too because it doesn't let them to organize their files. For example, a user can't redirect fish://aseigo@work.com/home/aseigo/Documents to /home/aseigo/Documents/work-docs (the most logical place, in my opinion). Such a redirection would however be possible with KIO-FUSE and XATTR.
i'd prefer not to see kde users punished for it by having lowest common denominator interfaces as their only choice.
Aaron, where do I send your well deserved pint or a monetary equivalent? :)
I agree, but with a KIO-FUSE...
I remember reading about FUSE somewhere in a thread discussing future Nautilus improvements. The developers essentially were going for that because of the mess of handing out remote links from Nautilus to GTK/Gnome apps. Nautilus would secretly pass the login settings to the app and it would log in again, and there was confusion with locking and all that mess. Hence was the shift to mounting remote things as local path through lower-level means.
I am not sure how this is done in KDE now but somehow it seems KDE doesn't have the same problems. Or does it? Would be a good planet article.
For my part, I certainly can't stand smbmount-ing shares and much prefer kio experience. I wonder if it's relevant to FUSE.
daniel: I remember reading about FUSE somewhere in a thread discussing future Nautilus improvements.
I just read over the very recent discussions of FUSE integration into Nautilus, and it seems that they have started to implement something on the lines of what I had proposed. This is reassuring :)
KDE doesn't have the same problems.
KDE's KIO slave have the same problem as Gnome VFS, but this can be solved with FUSE.
I certainly can't stand smbmount-ing shares and much prefer kio experience.
Smbmount-ing shares doesn't use FUSE. But with KIO-FUSE, it is possible to mount KIO smb files/folders, thus making them available to non-KDE apps.
Post a Comment