this week has been just insanely busy for me. i've been playing with kdecore, dealing with various devel issues around plasma land, participating in the release schedule discussion and the p-man was out of school for the last day and half. i have to finish up 3 presentations for my trip next week ... it's just one of those weeks where i feel a bit run ragged. and so not much blogging =) i wanted to show the neat new animation stuff in krunner, but the screencast one of the guys made for it didn't actually show it.. so.. yeah =P
some really good news, though, was found in mauricio's blog entry on kde computers sold in brazil. 18% of systems shipped with free software desktops there, making 1.5 million systems. the supported distros are all kde centric, so it's safe to assume they were installed with kde when they left the store.
if we use last year's numbers for retention (1 in 5 keep linux on the system, with the other 4 simply installing an illegal copy of microsoft's products) we end up with a number of 300,000 systems in the last year. that's five times what last year's data indicated. nice =) i can't wait to see things first hand next month at FISL.
now to make more countries like brazil ;)
Subscribe to:
Post Comments (Atom)
7 comments:
Animation in krunner? For some reason I don't see it.. Then again my checkout is a few days old.
One option I hope to see in KDE4 though is "disable fancy backgrounds". Yes SVG is cool and all but I can really live without krunner taking forever to regenerate its background image when you resize it. Same with ksysguard. The gratuitous SVG use doesn't really add anything and is a significant performance hit. And since it's so resource intensive to generate a SVG, we have every app writing their own caching algorithms to mitigate the impact.
> Animation in krunner?
click the options button. it's not complete (there are sizing issues; there needs to be a "drawer" section, really)
> really live without krunner
> taking forever to regenerate its
> background image when you resize
> it
how are you resizing krunner?
> doesn't really add anything
besides resolution independence, greater consistency between apps (since we can share imagery despite size requirements), composition techniques not possible with standard bitmaps (e.g. querying the image for the bounding rect of a given element by id so one can constrain the drawing of other elements) and having nice interfaces that don't look like crap ... well, yeah, not much i suppose ;)
seriously, a basic flat svg doesn't take much to render. it's the svg's with lots of gradients and complex paths that take longer.
> we have every app writing their
> own caching algorithms
that bothered me too. so i wrote Plasma::Svg, an image-centric class that takes the name of an Svg, loads it via Plasma::Theme, and does the rendering/painting on demand. it does internal app-global runtime cacheing; i'll probably end up adding a disk cache to speed up startups as well at some point.
any app in kdebase/workspace can use it right now. i expect ksysguard to eventually use it, for instance.
so yes, every app doesn't need to reinvent the wheel.
and perhaps it will move outside of workspace in 4.1 if there is demand/neeed for it.
> how are you resizing krunner?
Meta+Drag right mouse button.
Yes, I see you've gone to some lengths to prevent people resizing it. I guess I am just opposed to using SVG where it doesn't add any functionality per se.
Most of the advantages you list do not apply to krunner. The SVG background is there purely for aesthetic reasons. Whether that is enough to justify it is debatable. I would say no, because I would much rather have a consistant interface than one where every application has its own fancy background. As long as it doesn't spread to a lot of apps it's fine I guess.
Don't get me wrong, SVG is brilliant, and there are many good uses for it (kdegames) but I just don't see the value of the background to start with, and then making it the most complex to render image format you can get.
Anyway, enough complaining from me :) It's a minor thing really. Mostly for those with slow hardware. Glad to hear that the caching/rendering is in a place where others can use it.
> click the options button.
Ah now I see it. Very nice.
Oh yeah one other thing too. Not sure why this is done, but the background image seems to be checked every 250ms or so. Usually it will then report finding the cache, and show that. However, if you resize krunner, it will re-render, and if you resize it large enough, it will lock up because it always re-renders. I assume this is because it starts rendering, and doesn't finish before the next time event arrives, and it re-renders forever.
- how I hate captchas.. I never get it right the first time
> Yes, I see you've gone to some
> lengths to prevent people
> resizing it.
=) exactly.
> Most of the advantages you list
> do not apply to krunner.
actually, the only one that isn't applicable to krunner is the get-boundgings-rect-by-name item. the rest apply.
krunner doesn't use an exclusive background for this. it gets it from Plasma::Theme. you'll see the same background in the lock process dialogs, in the plasma desktop layer, etc...
and saying it doesn't have anything to do with resolution independence is mildly cute since you're actually resizing it ;) but yes, we're now ready for any display with any resolution.
there's perhaps a bit more to the whole design than may be apparent at first. *shrug*
> the background image seems to be
> checked every 250ms or so.
the blinking cursor in the lineedit causes repaints. move the focus out of the line edit and the paints should stop. given that it's just blitting the already rendered pixmap as necessary it's pretty light.
> Usually it will then report
> finding the cache, and show
> that.
unless you resize the dialog, it should -always- find it in the cache.
> and if you resize it large
> enough, it will lock up because
> it always re-renders
yeah, i haven't implemented resize compression as i haven't had a chance to sit down and think how i want to do that. the best option is to probably resample the pixmap to a certain % up and a certain % down for any given time delta before re-rendering the svg itself.
i also need to get around to time delayed deletion of the renderer and caching of the svg data in a qbytearray to free up memory (the renderer can be pretty heavy in that respect) while preventing further disk hits (to load the data again)
so.. there are several obvious optimizations yet to be made. and i'm sure there are probably a few non-obvious ones too =)
The only problem I find with such distributions installed by the factories area that at least one of the biggest factories decided to make a distribution for its system and the big problem on that is that it lacks some features like an easy way to installing new software, etc. But some of them come with really user-friendly maintance systems such as Mandriva, I wish one day I'll see one with SuSe :)
I like your blog.
Post a Comment