today is another travel day. i'm pretty much packed, just have to do up some dishes in the kitchen before the shuttle comes to take me to the airport in 3.5 hours. took zack (who i'll see again tomorrow at FISL) to the airport yesterday; feels like it's my second home sometimes.
thanks to the diligence of eva and the marketing working group, we're finally getting business cards for e.V. members and those who do KDE business. great work everyone!
plasma devel continues forward, despite my laptop slowly breaking down. i've resigned myself to the fact that i'll be needing to get a new one here real quick. once there's a new qt 4.2 snapshot and that makes it into qt-copy, i'll be able to check in more of my plasma work (which depends on, among other things, qgraphicsview). zack made great progress on qt-svg in the last couple of days as well, so that's all coming together.
also, many people have asked about searching in kde4. i've been talking with mandriva (thanks for hooking us up, tackat!) and they have hired a number of new bodies to work on kde4 and one of the tasks they are undertaking is working with the nepomuk project to bring the social/semantic desktop tools they are building to maturity with hooks into kde4. i was getting concerned about what direction we'd have for search in kde4, with beagle not really being what i wanted from a design perspective, kat taking a long time to mature and tenor stuck in the doldrums (though i have seen wheels around more again, which is very nice). i may yet be able to put some of the plasma contextualization features i had punted out to 4.1 into the 4.0 release. it's still early days, but good news that there are people working on this stuff full time now. (another couple of mandriva hackers will apparently be working on kde4 itself. thanks mandriva!)
it was really nice to see the kde commit digest back in action. kudos to danny allen for taking that on; it's a great asset to the community. then there was the first release of try kde, which is another canllaith project. i'm excited to see where that goes.
google's second "summer of code" is getting underway as well, so if you are a uni student be sure to submit your kde, koffice, kopete, etc ... proposals sooner rather than later. i hope to see a good number of realistically achievable and practical projects this year.
and with kde4 development actually starting to gather steam and spring having arrived, it feels like winter (both literally and metaphorically) is finally behind us.
cool/odd note: searching for open source on google video i'm on the first page ... twice. zoinks. i ought to get the video from mexico up on the net as well.
Subscribe to:
Post Comments (Atom)
14 comments:
To be honest: I think the KDE teams have to have a close look at the whole tenor/search machine situation because I haven't seen any real progress there in the last month.
I am one of the people who help to keep the kat-wiki clean from spam, and I am subscribed on the kat-development e-mail list - but I do not see any (!) progress there at all!
Maybe it is just because everything is developed indoors at the moment to be released in a almost ready shape when it is time, and I really hope that it is like that, but I do not think that KDE should bet on this since this development modell is doubtable.
Nepomuk sounds pretty interesting, but htere hasven't been any public release or anything else, so from a user point of view it is also a kind of hoping and a kind of a bet that it will turn out cool.
It is jsut not very satisfying since there are already very nice solutions ofr all of the other desktops.
The best thing to do I can see at the moment is to keep the possibility open to build a context and linking framework on top of a search machine layer to be able to switch between different search machines like KDE 4 will be able to switch between different sounds engines with Phonon.
An plugin-integrated beagle would be nicer as having nothing else which is wokring really good...
liq*very worried*uidat...
@liquidat:
> Nepomuk sou,nds pretty
> interesting, but htere hasven't
> been any public release or
> anything else
the reason why i'm interested, nee .. excited about this is that the development work is being funded on these projects. mandriva is paying people to work on the kde side and the nepomuk project has funding from elsewhere (i believe government, actually, though that could be wildly incorrect).
so finally we have people who can spend working day hours being paid to focus on the issues. this is why tenor, kat, etc, etc have all failed to produce.
> It is jsut not very satisfying
> since there are already very nice
> solutions ofr all of the other
> desktops.
there are search tools, but none of them are compelling in a manner that would make them centrally useful to the desktop over the next decade.
> build a context and linking
> framework on top of a search
> machine layer to be able to
> switch between different search
> machines
given the state of search engines (there currently isn't an open source desktop search system that really offers what is needed for desktop development) and the lack of maturity when it comes to feature set standardization (which vary wildly, unlike media or hardware which have generally settled into fairly predictable patterns by this point), i just really can't see how this would be feasible right now.
one could offer a simple "give me files back, and optional some more info, given this search term" type interface, but we need a -hell- of a lot more power than that.
[i]but we need a -hell- of a lot more power than that.[/i]
I think that's the classic "Nobody have the solution till we implement it"
Ain't nothing but fanboy bullshit to me.
Aaron: thanks for the answer!
And I think we really need a multi language support in KDE to have the ability to spellcheck not only in your native (e.g. kcontrol defined) language but also in others like english - there were lot to much spelling errors in my comment :(
liq*not a native english*uidat
It's a bad news that Tenor is abandoned for months :( It's one of the key features of Mac OS X, Windows Vista, and Gnome (Beagle).
Vista solution seems to be pretty limited, and Beagle is totally useless, so I did hope to see very active work on Tenor which would bring great API and then prepare the implementation work...
Overall, I have the feeling that the whole "kde4" project is still very "community driven" (like in "camel is a horse designed by community") - there's no central plan, I don't see the common vision and the whole Wiki's "KDE4 Plan" is simply a list of structural changes to current KDE3.
What I really lack is a mature front end paradigms that would present the goal of KDE4 - it's feature set. Then I'd expect UML diagrams to prepare the whole library API and then real implementation.
Instead, at least from external point of view, it seems that group of hackers is playing with feature set of plasma and qt4.2. And then, once they have plasma ready, they'll rethink what to build on top of that plasma thing which is totally opposite of what should happen imho.
It seems for me more like a development of old Mozilla Suite where developers were just developing whatever they wanted and then whatever was mature enough got into the release, than Firefox development model, where you have exact UI diagrams and feature set plan as the first part of the planning.
Tenor is a great example. If we'd had a set of features, plan, vision, detailed graphs, lists and early UI proposals, and then get the "kde team" to implement them, there would be no way to have "abandoned" part of the system.
But if the situation is that there's a virtual project "appeal" and then there's a project "tenor" driven by one volunteer, and project "oxygen" driven by another, then it's way easier to find one of them abandoned.
Also, the very big problem with such model is total modularization which is sooooo visible in KDE3. Every part lives on it's own, because there's no common vision of how KDE desktop should looks like - tere's a set of pieces that were ready when KDE was released, so they were checked in.
It makes bad to consistency, reusability, and usability itself.
I'm still waiting for the day when KDE team will put request for "User experience team" and "Product management team" and those two start actual work on KDE4, to prepare the visual plan that will be later developed in code. This way, we'll see a desktop. In the opposite model, when coding is the first idea, and every component lives on its own, instead of user oriented desktop we're getting developer oriented set of components.
make a lot of project make kde dynamique, but what kde need is a strong base and many things around.
Force strict plan is not always a good idea, specialy with open projects.
For exemple, you dont plan to use X3D tools, and you discover that it would be usefull for kmplot and not so hard to make it working through plasma buy khtml (it is not real) if you can't changes plan you can't make it for the new relase.
ps: sorry for my english
> It's a bad news that Tenor is
> abandoned for months :(
not sure why people aren't getting the fact that we now have a solution in the works that is being worked on by -paid people-.
which means the "too bad tenor is abandoned at the moment" becomes "hooray! we have a solution being actively developed!"
> It's one of the key features of
> Mac OS X, Windows Vista, and
> Gnome (Beagle).
none of these systems are remotely like Tenor or a "semantic desktop". they are search engines, which are similar but different.
again, users don't really want a search tool, they want the ability to reveal connections and quickly find things through context.
> it seems that group of hackers is
> playing with feature set of
> plasma and qt4.2. And then, once
> they have plasma ready, they'll
> rethink what to build on top of
> that plasma thing which is
> totally opposite of what should
> happen imho.
you have no idea what we're doing or thinking because we -did- start with high level user interface concepts and then worked -downwards- to the code/technology design required to support that. that is what i'm working on implementing currently. that's also why it's taken so fucking long: i started from the end user experience result and designed that first.
> If we'd had a set of features,
> plan, vision, detailed graphs,
> lists and early UI proposals, a
we had -all- of those things. we even some database schemas you could load and play with!
> and then get the "kde team" to
> implement them
this isn't how open source development works. the "kde team" isn't a magical resource that springs into being whenever someone says "do it!"
> KDE team will put request for
> "User experience team" and
> "Product management team" and
> those two start actual work on
> KDE4,
your wait is over. the "user experience team" is called the "human computer interface workgroup" and the "product management team" is called the "technical working group" and both are currently active on kde4.
sounds like your problems are from a few years back at this point and we have identified them already and even put in place solutions for kde4.
i'm sorry, but it really frustrates me to hear people make suggestions as if the wheels are falling off the project when we ALREADY HAVE ADDRESSED THESE ISSUES.
instead of trying to pontificate, ask questions. you may end up surprised at the answers. at worst you'll know that your fears are true and -then- you can offer your insights.
Where can I get source code of that new Tenor replacement?
again, users don't really want a search tool, they want the ability to reveal connections and quickly find things through context.
You are of course right. It may be my misreading, but the target of the tool is to be usefull for Mandriva desktop plan, not for KDE desktop plan, which might be not the same.
Also, their mission seems to be to create a complete solution, instead of preparing low-level API for KDE. This means, that instead of having great KDE API on which any part of KDE that wants to use its features can base, we'll have a ready to use low-level+high-level+ui tool that will just work. Another module not tied to others, with it's own roadmap, plan and goals. It's a problem.
See, looking at their site, reading their summary, objectives etc, I don't see any word about "We'll give you the API that you can use in your app to make context search fast." - which means, it's not solving the problem that Tenor (if I understand it) should solve. Instead, they write a lot about "comprehensive solution" and "a comprehensive solution for extending the personal desktop into a collaboration environment" - they're creating desktop environment. How it'll work in pure KDE4?
you have no idea what we're doing or thinking because we -did- start with high level user interface concepts and then worked -downwards- to the code/technology design required to support that. that is what i'm working on implementing currently. that's also why it's taken so fucking long: i started from the end user experience result and designed that first.
That's awesome! Why the ordinary users, who'd like to step in and help, can't see those plans?
Aaron, I admire your work, I love kde, and all what I'm writing is because I want it to be successfull, don't find any of my words offensive - it's just a point of view of a person, who see what I described.
But, back to my question, why there's no public plan for KDE4? So people can discuss the solutions and problems, and suggest better solutions or new problems. Why the community can't see this "Vision".
Look here:
- http://wiki.mozilla.org/Firefox2
- http://wiki.mozilla.org/Firefox:Home_Page#Firefox_2.0_.28Bon_Echo.29_Plan
How much time do you need to get ALL the knowledge needed to understand what Firefox 2.0 will be from the user perspective?
You can later digg to find exact API, tech. solutions etc. but first of all you can see the vision. And for KDE4 I failed to find this :(
instead of trying to pontificate, ask questions. you may end up surprised at the answers. at worst you'll know that your fears are true and -then- you can offer your insights.
Aye sir. So, my question:
- Where's the KDE4 UI draft, product plan, planned feature set?
I'll be probably the most happy person in the world when I'll be reading those docs, because I'm 100% sure that you're doing a great thing, I just miss ability to know WHAT you're in fact doing :)
@gandalf:
> But, back to my question, why
> there's no public plan for KDE4?
> So people can discuss the
> solutions and problems, and
> suggest better solutions or new
> problems. Why the community can't
> see this "Vision".
because the 'community' you speak of isn't involved in development. and not because we keep people out but because people usually just don't get involved.
kde is a meta-project: we are made up of dozens if not hundreds of discreet projects. each project discusses and maintains its own feature set and goals with things that affect everyone discussed on kde-core-devel. these things may be recorded on wikis or just left in the email archives.
the important thing is that each development team knows where it is going. and through discussions between the various teams, we tend to coordinate our individual visions.
> Why the ordinary users, who'd
> like to step in and help, can't
> see those plans?
i'm not sure what an "ordinary user" would be able to contribute code-wise. if you wish to get involved with artwork for kde4, that's the oxygen project (they have a website and a mailing list). if want to get involved with documentation, it's a bit early for kde4 yet but they have a mailing list too. if you want to get involved with QA, then tracking KDE4 once we start releasing technology previews would be awesome.
the release plan is still being put together: the technical working group survey the project a few weeks ago for final input on outstanding issues in the libraries. but these things take time on a project of this size doing a new major release, and our focus is on getting these tools together for developers more so than the userbase to comment on at this point.
@ramses
> Where can I get source code of
> that new Tenor replacement?
partly from the nepomuk project with the kde integration coming out of the mandriva team. this is a relatively new venture, but it is both funded and the nepomuk project has some past energy to bring to bear.
Aaron: You see? You're pointing me:
- if you want do graphic, go to Oxygen
- if you want to do QA, go there
- if you want to do X go to Y
And where should I go to be able to take a overlook on the KDE4? To get the mid-precize vision on what KDE4 will be (mid-precize - I don't need screen by screen every part of UI, but on the other hand, I'm not looking for two words overview) - you said that you prepared the plan for UI/feature set before starting your work.
Why is it not public? What are the reasons against it?
Community might help, if they share your vision, and you did not publish the KDE4 vision. And help is not only QA, coding or graphics. They can prepare promotion, they can think of a better solutions that you invented, they can give you fresh ideas.
I'm afraid that such a lack of public documents raises the feeling that Open source is unpredictible because no company can plan their long-term roadmap including KDE4 at the moment.
I see tons of cons, and no pro of keeping this "KDE4 front-end plan" hidden.
加气混凝土设备
砌块机
模压瓦机
超细磨
粉碎机
砌块成型机
彩瓦机
木粉机
鄂式破碎机
反击式破碎机
锤式破碎机
破碎机
鄂破
对辊式破碎机
加气混凝土
木屑机
制砂生产线
石料生产线
砂石生产线
加气混凝土砌块机
球磨机
选矿设备
磁选机
输送机
锤式破
烘干机
振动筛
制砂机
洗砂机
榨油机
彩色路面砖机
破碎机
橡胶磨粉机
破碎机
反击破
对辊破
破碎机
锤式破
雷蒙磨粉机
雷蒙机
磨机
加气混凝土砌块
超细微粉磨
液压砌块成型机
皮带输送机
选矿设备
加气混凝土设备
磨粉机
鑫源
漫天飞舞
Post a Comment