I've finally managed to get the last bits of the KDE 3.2 Alpha 1 (codenamed "Brokenboring") including KDevelop 3.0 Alpha 6
on the ftp server. The mirrors should soon pick it up.
There won't be any binary packages for this release because the KDE "Pi"
release is coming out soon. Everyone using Brokenboring is asked to
compile it with --enable-debug, so that we can get valuable feedback. There is a new unstable version of Konstruct also available to install it.
Other than that, feel free to play around with things, check if your bugs
are still there or if there are places where you can help. Check
the KDE 3.2 feature plan
for things to look for.
The code is quite rough in many places, but many of the developers
use it on a daily base and kdepim has improved so much that you can't live without it once you've tried it. :)
Thanks to everyone who convinced me that the code is good enough for
a release when I was tempted to drop the idea altogether. Just one final wish: check
for duplicates before you file bug reports and compile with debug information enabled
before reporting crashes -- you might find tons of bugs, but with
debugging information the chances we can fix them are much higher.
Comments
yeah..
i can write excelent code !!
trust me.
ok, ok, i'll only donate crappy code because that writes faster.
but if i would want too....
what point is there in "being able too" when you don't "do" it
but back on topic:
let's just see what will happen in the "bug fix" weeks.
we will then see how real the "duplicate bugs" thinggy is.
after that we will see what is left and what needs fixin before 3.2
how is that with you?
When you say 'everybody's comprehension ability.', it should be 'everybodys' comprehension ability.'. This is because the comprehension ability belongs to more than one person. When it is both belonging to and plural, the apostraphe should be placed after the 's'.
So what about some sort of page giving impression what programs should/might/could be integrated to the KDE-3.2 release?
For example k3b/cdlabelgen, kphone and kpdf start to look usable enought for being included on all distribution configurations... ?
kdeextragear-* isn't a place where apps are supposed to mature until they are ready for integration (that's what kdenonbeta is for). Please see http://extragear.kde.org/home/about.php which lists several reasons why the apps are in those cvs modules.
Christian
Yeah ok, I know, but the thing were that atleast all main distributions consider the k3b as the default CD/DVD burner nowdays, that's why (atleast to me) it would make sense to include it with the release sonner rather than later...
And atleast to me it sounds a bit silly to keep that kand of functionality as "extra packages" for users to choose as most computer systems sold nowdays have atleast CD-RW if not DVD(+/-/+-)DVD drives.
Of course there is also the cdbakeoven-thingie around, but it is becoming rapidly obsoleted (like kreatecd has already) by the k3b as k3b-0.10(cvs) also include quite extensive DVD support via dvd+rw-tools.
Sure major features missing from it (IMHO) are DVD ripping (discussed in that past too, something similar to quickrip) and as the user interface is actually quite close to konqueror (in file browsing mode) itself, so why not make it a internal part of the konq itself (simple side-card?)?
And as cdlabelgen/kover feature also would make it closer to burning software in conpetitive operating systems...
kdpf may be in KDE 3.2. k3b perhaps in the next but one KDE version, an inclusion into KDE would likely more slow down its development at the moment than help. Never heard of kphone being developed in kdeextragear-* and it's perhaps not as useful for the same amount of people as the other two.
Did look it up again, and notices that I was wrong! :-)
There just were a directory in kdenonbeta (and yes, not in kdeextragear) but that dir was actually empty, maybe someone in the inner circle could explain it that something for the future, or some mishap from the past?
More software that would make it more simple to come to conclusion what packages should be included without sacrificing functionality on average Linux distributions by suggesting what other packages could be eliminated:
kmyfirewall (so there would be synerged way to control simple personal firewalls)
kmplayer (Mplayer support much much more codecs than todays noatun/kaboodle/xine/xanim hassle)
kplayer (yes, not yet worked on kde HEAD, but would eliminate pretty efficiently noatun/kaboodle)
I think it's a good idea to remove cdbackoven and just stick with K3b. There is no reason what so ever to include two applications that have supposedly the same functionality/purpose in the KDE repository. If someone wants to develop his/her own CD burner app, that's perfectly fine, but we need to include ONE application for each SPECEFIC purpose, not two.
Another example is KRec vs. KRecord, make up your minds and choose one of those, don't confuse the user.
Totally agree with you. Besides, K3b is the best.
For what it's worth, I agree too.
What?? I don't understand you. What is KDE?? Huh! Why is it being duplicated?
Has anyone tried modding KDE apps to throw/catch Dashboard cluepackets?
( http://www.nat.org/dashboard/ )
The project looks very cool, and the interface is pretty platform agnostic. In this respect KDE and Gnome apps could easily become more mutually integrated than windows programs are. (Of course, once the interface has stabilized it will be nice to have Dashboard recoded natively :-)
I had an informal look, and it seems the first step needed would be to create a backend for it. The backend basically takes the clues, and adds it's own clues - this is what dashboard is all about.
An example for this would the whole kontact thing. So then gaim or the kde equiv. would throw a clue packet for a particular person, then kontact would add information about that person, to be shown in dashboard.
Once that is up and running, a port for the actual dashboard client would be nice, and so on.
Personally, I think dashboard will be ignored for ages, then almost overnight become huge.
At the moment unfortunetly there seems to be a pause in development on it.
I saw in the Feature plan that RDP support for KRDC is still listed as "In progress", though I finished it about two months ago. Where should I report it as being finished?
You can change it yourself (I guess you have a cvs account).
Checkout developer.kde.org/development-versions/kde-features.xml and just commit your changes.
Yes, it worked. Thanks.
Hello slashdot user: http://slashdot.org/~ThyTurkeyIsDone.
just posted this here: http://developers.slashdot.org/comments.pl?sid=78055&cid=6929804
In stead of removing posts, why doesn't the dot move to a score based forum?
There really isn't the slightest need to provide a support channel for the garbage you've linked to above, IMHO.
Because it is just an excuse for stupid trolls. "If you don't like my comment, mod it down"...
he also posted it here:
http://slashdot.org/comments.pl?sid=76833&cid=6845043
and
http://slashdot.org/comments.pl?sid=76772&cid=6840235
Wow, what is wrong with this guy? This was funny a long time ago, but it's just redundant now.
Can someone provide us with some screenshota of new cool things not-yet shown on dot.kde?
I personally would like to see the WYSIWYG mode from Quanta.
WYSIWG mode is still work in progress, and we hope that it will be ready for 3.2 (this is why it is in the feature plan), but it is NOT a promise.
Andras
es, I know, but I still want to see it ;)
Well you can throw Quanta into preview mode and have a look and it's a lot like that. ;-) There are a number of things that need to be done underneath to bring up anything substantially different in visuals there. There's not a lot to see but a lot of code. There are other things that are more visual at this time. For instance there is the new attribute inspector that lets you edit tags in either mode. We also have made KFileReplace into a plugin and it is in CVS right now. Some of the things it does are the most requested features for Quanta. KFileReplace is the ultimate multi-file/directory, multi-line, wildcard enabled find and replace I've ever seen. It's very cool. Also plugins can be loaded in file tabs now. I'm attaching a snapshot of the CVS version from a little while back running in KDE 3.1.x. Note that the plugin toolbar was something experimental I did but it is easy to do. Our most popular plugins are on the main toolbar now.
Enjoy!
It's good to hear that easier tag dialog will get.
I've made sometime ago a better body dialog that never got into Quanta and I think most dialogs miss important tag options today. Maybe now, we can improve this part in Quanta ;)
> It's good to hear that easier tag dialog will get.
Maybe that lost something in the translation... but yes, we have lots of options now including full auto completion with code hinting, the tag dialogs and the new attribute inspector which lets you navigate and edit tags. Next on the list is to get Visual Page Layout ready.
> I've made sometime ago a better body dialog that never got into Quanta and I think most dialogs miss important tag options today. Maybe now, we can improve this part in Quanta ;)
I have to say something about this because it's really frustrating. I'm sure you'll understand. First off, the old body dialog was a custom hand built dialog that was not at all compliant to any DTD or good design criteria. All the original dialogs were very HTML 3.2 and very much in need of deprication. All the current dialogs, with a few excpetions, are generated from Quanta's tagxml. I admit some lack non compliant things like name attributes for images however I tried to add all W3C compliant attributes with tooltips explaining anything depricated. Somewhere in a cleanup someone *cough*Andras*cough* must have removed some of that but our current dialogs have been reviewed extensively. It's entirely unfair to say that most are missing important options! Some, in our release versions, have attributes missing.
Currently in our CVS we have 21 DTDs, psuedo DTDs and Schemas supported. Thesehave been worked on and reviewed extensively and include several HTML and XHTML dialects versioned for strict, transitional and frameset. Seriously, I doubt there are many tools even close for hundreds of dollars. I just have to say, if you found something not right you need to file a bug report or post it on our user mailing list so we can address it.
As a further point... you can edit, update, change, fold spindle and mutilate dialogs to your heart's content in real time. All you need is a folder in $KDEHOME/share/apps/quanta/tags/[dialect] which you insert the tag.tag file such as body.tag and Quanta will substitute that tag. Our upcoming version has (in CVS) a tagxml editing environment so it's easy to edit and create here.
One last thing. You can also create Kommander dialogs. I've attached a screenshot of our new Quick Start dialog. What is cool about this is that you can also edit and change it to meet your needs using the Kommander dialog editor. It's built visually.
So please excuse me for saying this... but it's so frustrating to see people saying "maybe now we can change or customize X in Quanta" when I've been saying for the last year that we have been working hard to make it so you can. If more people understood this they would realize you don't need to know any C++ to be very helpful contributing to our project. We need these types of contributions worst but everybody still thinks they need to know C++ to help us.
I understand, I said that just because I get a bit sad when I did the manual work of editing the body xml for tag edition and it never got in Quanta I don't know why.
That's why I said editing those dialogs is a great thing, you can customize your dialogs even that they never get into the main branch :)
My complain about quanta is that there are a lot of good ideas in sourceforge project page that never got attention, BUT I'm no one to complain because I don't pay for Quanta and don't help developing it (I hope I do in the future, I'm already learning C and I hope next year I get C++ knowledge enought to help out), so just ignore my trolling, sorry.
> I understand, I said that just because I get a bit sad when I did the manual work of editing the body xml for tag edition and it never got in Quanta I don't know why.
Did you send it to me? If it fell through the cracks I apologize. That can happen with a million and three things going on. If it was unacceptable for some reason then pretend I didn't answer this. ;-) You would really need to check CVS to see what's happening. If you see something wrong and it's not addressed you have my permission to bug me until it is. If I have a reason not to want to do it I will tell you. I'm not shy.
> That's why I said editing those dialogs is a great thing, you can customize your dialogs even that they never get into the main branch :)
And that's the great thing because there are reasons we don't want to do some things and you shouldn't need to care. I was just trying to understand what happened.
> My complain about quanta is that there are a lot of good ideas in sourceforge project page that never got attention, BUT I'm no one to complain because I don't pay for Quanta and don't help developing it (I hope I do in the future, I'm already learning C and I hope next year I get C++ knowledge enought to help out), so just ignore my trolling, sorry.
I never ignore users (I respond to nearly every email) and I espeically try not to ignore potential developers. I don't know what ideas you're referencing but I did update the page a while back. We're also in work on a number of things and others we just have in the queue until we have someone there. In order to be fair you need to be more specific. Feel free to email me.
I should point out that I did not know C++ when I started on this project and I have had to learn it. If you really want to get involved don't think you need someone to walk you through what a class or a virtual function is and hand you a piece of paper saying you're a programmer. (not that there's anything wrong with that) There are lots of resources and you get get on the developer list and kde-devel, read, practice and ask questions. In practice motivation always beats skill. Skill without action does nothing and motivation will eventually succeed. So take action.
I did posted on patches section on sourceforge, no hard feelings on this, my point is just that users should not be dependant of quanta developers all the time. We must help quanta development in any way we can, and if not, use this versatility of quanta to make for us a custom version that satisfies our needs. :)
Sorry my english, I just existed from a.. well, a english class, hehehe, I'm a little sleepy :)
Anyway, I think you're a nice person and is a example as developers should hear their users Eric.
Anyway, to put a end on the discussion, how can we help to improve quanta tag edition dialogs? I understand that you are only accepting W3C rules, is there a place where we can learn all tag options, compare with quanta and map the missing ones, so that they can be place in quanta?
Thanks in advance and reguards.
I saw that ksvg has been moved from kdenonbeta to kdegraphics. Does this mean it will be included in kde 3.2 final.
Anyway, thanks for the great work to all kde developers.
Yes it will be in kde 3.2 release.
So the file base for the kde seems to grow for every generation, I just guess will the kde-4.0 gonna have even more packages?
Could there be some sort of package combination scheme executed during the kde-3.3->4.0 move?
For example releasing arts within kdelibs and kdesdk could include kdevelop and quanta... Why not, sure as thay are separate as the teams are working somewhat separate, but that would help the dependancy hell (overlapping eliminated) and even might start combining of those separate user interfaces (kdevelop looks pretty similar to quanta, so why not combine them?)?
WYSIWG mode is still work in progress, and we hope that it will be ready for 3.2 (this is why it is in the feature plan), but it is NOT a promise.
Andras
Sorry, I posted under wrong thread...
Kdevelop & Quanta are similar (and will be even more similar), but the codebase is quite different nowadays (as both were rewritten independently and KDevelop's core is completely changed, while Quanta is partly based on an older KDevelop core) so merging them wouldn't be a trivial task. I don't say it will never happen, but right now it's not possible. But we will try to reuse at least the MDI framework (KMDI) and some KDevelop plugins in order to reduce code duplication and bloat. For me this seems to be somewhat similar to the KMail/KNode case, altough I don't know what are the code differences between them. For the user it seems to be trivial to merge the two products, but for the developer it isn't.
Andras
Understand it perfectly, it's pretty common to make software that acts exactly the same way, while being 80% different code.
But what about that file regrouping, as I bet virtually everyone that install kdevelop install also atleast kdesdk and I bet most install also the quanta... So why not bunch them all to single file (to kdesdk?)?
It might be simpler to start clearing duplicate code first and then start synergizing the rest after that... ?
> Understand it perfectly, it's pretty common to make software that acts exactly the same way, while being 80% different code.
Actually that's not really an easy statement to agree or disagree with. For instance looking at Kdevelop and Quanta, they both use the same base of KDE/Qt libraries. It is a coincidence that Quanta is based on Kdevelop 1.0 but both have been largely rewritten since then. Kdevelop also has a lot more developers so they have the luxury of approaches difficult for us. We also use similar things like editing components and plugins. Beyond that, the way software is so inherently flexible, there is no re-use that isn't designed to be reused. Appearances mean virtually nothing WRT base classes and approaches.
> But what about that file regrouping, as I bet virtually everyone that install kdevelop install also atleast kdesdk and I bet most install also the quanta... So why not bunch them all to single file (to kdesdk?)?
Are you volunteering some time here? (I have to wonder why I'm answering "nobody" but I'm sure it's of interest to sombody) First, we're talking a huge module. Second, translators only need kdesdk. Third, I only wish more kdevelop users/developers tried Quanta because they are doing cool things for web related stuff for kdevelop, but the two packages are somewhat variant in their missions. We'd love input from developers we didn't have to explain KDE/Qt to. There are other issues, but I'd like to be able to develop the Quanta module into a weblication suite. We already have Kommander in there. Eventually more related and pluggable apps could be there. Finally there are a lot of web developers who don't want to ever delve into Kdevelop or all the things it has for application development. It's also a big source package. In short order you're talking about the biggest module in KDE. Not everyone has the bandwidth.
> It might be simpler to start clearing duplicate code first and then start synergizing the rest after that... ?
Yeah... that sounds really good. Unfortunately there are problems with it. First of all what's a one for one duplicate and what dependency issues does it create? Not to mention... which one do we keep and which one do we throw away? I don't want to disparage your suggestion because your objective is not without merit. Your approach however is not pragmatic. You're talking about a whole bunch of work!
At the recent KDE get together some Kdevelop developers and Andras discussed this very thing and Andras and I discussed it. Let me give you my position, which I think is fairly close to most people involved. Ideally I believe that both applications have different missions and that as one moves more to the mission of the other it just won't do it as well. It can do it adequately, but not excellently. We insist on being excellent as does kdevelop so we need to not compromise some things. I think it is essential to have the different packages. My personal opinion is a lot of what they do supporting web development has to do largely with their familiarity with that tool and wanting to use it. However much of it was initiated when Quanta was not part of KDE formal and some started when it was not yet clear I would not allow Quanta to die.
After all these arguments in conflict with what you said you might be surprised that I very much agree with you in principle. I really believe that the two code bases need to become as interchangeable as possible. Frankly I'm really impressed with their plugin system and a number of other things... we just didn't have the resources to quite match it. I still think our plugin system was an elegant solution given the problem. Ideally I'd like to be able to use their plugins and gravitate toward more interchangability of the code bases. This would mean things developed for either application could be interchanged. I'd like to adopt other things from kdevelop too and I want to work together with their developers and keep an open dialog. Of course what would be even cooler is getting more developers involved so we could have the luxury of doing more.
Over all it's far less of an efficiency matter because that ignores progect directions and differences inherent to objectives. It is more of a synery issue where various aspects can merge and realize benefits. Expect it to take some time.
How I and my research team use both kdevelop and quanta is to make basic C/C++ and XHTML/XML stuff so I personally haven't been able to slice enought time to start looking at actual kdevelop/quanta source codes, but after projects I'm involved come to production level, then my team will need to get something new to do until there is next generation of hardware pruction line ready thus getting seriously involved with the KDE has been discussed between my team and organization big cheeses...
So at the earliest for the kde-3.3/4.0 generation we should be ready to make some tasks kde-people need to get done without any funds being blown. ;-)
Of course we are more experienced with hardware design than software, so our software expertise is certainly not top-notch, but I bet there is enought janitor stuff to be done...
Ps. The name comes from the fact that I'm "nobody" until we can come to the public (one part of our project include full Linux distribution) with our technologies. :-)
> How I and my research team use both kdevelop and quanta is to make basic C/C++ and XHTML/XML stuff so I personally haven't been able to slice enought time to start looking at actual kdevelop/quanta source codes, but after projects I'm involved come to production level, then my team will need to get something new to do until there is next generation of hardware pruction line ready thus getting seriously involved with the KDE has been discussed between my team and organization big cheeses...
That sounds great! BTW my condolences on working with Basic. ;-) There's a lot of stuff in the works on Quanta, as well as in our CVS, that most people don't know about. One delay working to accomplish the task of partially merging the projects is that we don't want to stop feature development for a major point release. (Believe it or not we only have a few developers.) Minor point releases can't add new UI objects that need translation. Clearly the ability to get a tool that does what you want making you more productive is far more compelling than any cost per seat analysis because developer time is always the most expensive part of the equation. I'm frankly surprised more companies haven't moved to commit a fraction of their IT expense to OSS projects that have the potential to slash costs over time. If I can be any help let me know.
> So at the earliest for the kde-3.3/4.0 generation we should be ready to make some tasks kde-people need to get done without any funds being blown. ;-)
If you would like to do collaborative efforts on Quanta please give me as much lead time as you can, as well as your objectives. We are currently in a feature freeze for KDE 3.2. It would be nice not to have to maintain a branch solely for lack of planning. I could also answer questions addressing current timelines and plans which might be helpful to your people too.
> Of course we are more experienced with hardware design than software, so our software expertise is certainly not top-notch, but I bet there is enought janitor stuff to be done...
Actually we designed Quanta so that a whole lot of things can be done with XML, scripting (any language the shell can interpret) and Kommander dialogs. Anyone with C++ abilities will probably like KDE programming a lot. Our policy is that if you can contribute messy code that's faster to clean up than write, we like you. Even better if we can show you how to clean it up. ;-)
> Ps. The name comes from the fact that I'm "nobody" until we can come to the public (one part of our project include full Linux distribution) with our technologies. :-)
Your secret's safe with me, but I knew that if somebody was nobody then nobody had to be somebody. Seriously, we're all about building the best web tool in the world. So as long as you don't tell me your CEO is a loud bald guy who does the monkey dance we're off to a good start. ;-)
After we get our stuff polished for the masses, then we get in touch for more serious chat about it...
Keep it kool! ;-)
Ps. Fortunate enought to be able to forget (replaced with HDL, C/C++ and friends) most of the Basic/Pascal/LISP stuff I needed at school. :-)
I think KDE should be split up a LOT more than it is. There are so many things that are included in the base packages that I don't want at all, so I have to do:
DO_NOT_COMPILE='a b c ..' ./configure ..
whenever I'm building things, just to get the 1 or 2 useful apps that are included.
It'd make life (for me :) much easier if each program had its own tarball. Some things seem to be included in KDE just because that's the way it's always been, and we're stuck with a boatload of programs many of us don't use.
You know, the ideal situation would be a web interface that has you check off all the programs you want. It'd check dependencies, then generate one nice big tarball of the programs you want. A single configure and make and you're set. I know that'd be taxing on the server and hard to maintain, but man, I would love that.
I'd donate a couple hundred bucks if such a system were put in place.. :)
Is there some way to get a list of the a b and c in that configure command?
> It'd make life (for me :) much easier if each program had its own tarball. Some things seem to be included in KDE just because that's the way it's always been, and we're stuck with a boatload of programs many of us don't use.
It's your distro's peragotive to split KDE packages into smaller packages. If they don't, it's their decision and perhaps you should switch distros.. debian does this for example.
I know that's how you think it should be, and that's how it currently is.
I'm saying that's now how I want it to be.
You can't argue with that cause it's an opinion.
So, what are the big improvements to KDEPIM?
I'm especially curious wether there will be more documentation on KARM (and it's logfile) or wether it'll have export capabilities..
I understand that the shadows under windows patch was included in the CVS but i cannot find it anywhere on KDE 3.2 alpha 1. Am i doing something wrong ? I have to uncomment some stuff in config files or add some stuff in kwin config file ? I need that cool thing :(
Who says that it's included?
The shadows are a major hack and way to slow to be included. I think there is a patch at kde-look.org that does this but we already had numerous bug reports where kwin was crashing due to this patch, so I wouldn't recommend it
Cheers,
Daniel
I've been using the patch with HEAD for a few months without many problems. Earlier versions of the patch were very buggy indeed.
However, as expected, it needs a fairly good computer. I don't know how good; it's perfectly fast on my Athlon XP 2200+