KDE-CVS-Digest for July 2, 2004

In this week's KDE CVS-Digest:
KWord now can mailmerge from KSpread as data source.
Less flicker in Konqueror and Kicker.
And many bugfixes in KSnapshot , Konqueror, khtml and KMail.

Dot Categories: 

Comments

by Eike Hein (not verified)

Nothing like Saturday morning ... fresh baguettes, fresh coffee, fresh CVS Digest.

by john (not verified)

In kmplot (and I guess everywhere else), the "view source" code comparison output is very impressive and looks like something we would like to use - how was that generated?

by Derek Kite (not verified)

It's in the kde cvs repository at www/areas/cvs-digest/enzyme

http://webcvs.kde.org/cgi-bin/cvsweb.cgi/www/areas/cvs-digest/enzyme/

enzyme_diff.php, enzyme_diffparts.php are the pertinent files.

If you have any suggestions please email.

Derek

by john (not verified)

Thks for the info - I think this would be really powerful if the php programs could be integrated into KDevelop + subversion to be used in regular application programming (though I guess you could say it is being used in the production of KDE). Very nice effort - will make code review far easier.

by Derek Kite (not verified)

kompare works well on the desktop.

What this and webcvs have are ways to view the repository differences, ie. extract patches. A necessary tool for collaborative development. Somehow having apache and php running on one's machine for development seems overkill.

Derek

by hein (not verified)

Hmm,

1. A Personal desktop assistent :-)
2. Speech sythesis and recognition
3. VRML+ Modules
4. video processing
5. A Planner tool for Kontact
6. a nice chess client
7 Yast integration

by Plake (not verified)

I'd chose more and better Scientific Stuff!

Mostly frontends to already existing stuff like R, Maxima, Yacas, Octave. Shouldn't be that complicated and I bet most of the projects would be willing to cooperate. This stuff would be much more mainstream if there were nice interfaces with integrated tutorials etc. (take a look at MuPAD for instance).

Ah and have board games providing standard interfaces for external programs to connect and play!! That would be excelent as they could be used to test other peoples Artificial Inteligence modules really easily!! That would attract lots of great coders!!

Oh and KDE/Qt bindings to functional languages, preferably Haskell.
Gnome will end up owning all Haskellers because of the GTK+ and WxWindows bindings. There are lots of them and it would be interesting to reach a wider variety of great coders.

by Richard Dale (not verified)

Ashley Winters (PerlQt/Smoke scripting language independent lib designer) is working on a O'CamlQt binding - I don't know if he has a kde version planned. How does O'Caml compare with Haskell?

by Plake (not verified)

I've never used it, thought the main differences are probably that Haskell is lazy and purely functional, while O'Caml is strict and impure. It can still probably be of some use though if someone's giving Haskell bindings a try.

I wouldn't expect it to be that complicated to do. Like I said there are GTK and WxWindows bindings. These are C libraries, but KDE C bindings are there for the purpose of inteface with other languages right?

Also it is possible to interface Haskell directly with OO Languages.
Here is a paper that discribes Haskell Objective-C bindings on MacOSX.
http://www.cse.unsw.edu.au/~chak/papers/PC03.html

Anyway, I might be wrong as I have no experience in this sort of task (otherwise I'd probably be giving it a try myself).

by ac (not verified)

- Releasing the core independenly from the applications

Core: kdesktop, kicker and konqueror, kdm, arts, and all the system daemons
-> kdelibs and kdebase

The "normal" applications should be released whenever there is a need
or a new version available.

Thank you for KDE, it rocks.

by Eric Laffoon (not verified)

> Oh and KDE/Qt bindings to functional languages, preferably Haskell.
> Gnome will end up owning all Haskellers because of the GTK+ and WxWindows bindings. There are lots of them and it would be interesting to reach a wider variety of great coders.

Take a look at Kommander, which is coming along nicely. Kommander visually builds the GUI using standard *.ui format files and the editor is currently based on Designer, though that will almost certainly change in 4.0. It has a concise and useful set of internal functions based on very quick internal DCOP and can be externally DCOP scripted from any application or the command line. It can also integrate any scripting language. I'm not familiar with Haskell, except having heard of it, but any compiled language with DCOP bindings should be easy to integrate with Kommander applications too. In fact you can have multiple scripting languages in the same dialog or even the same bound widget. Additionally we are in work on MainWindow support and free slots running scripts.

Kommander is one of KDE's best kept secrets which will work well for:
* scripters wanting GUI interfaces - any language the shell supports!
* prototyping
* users wanting to extend and integrate with KDE
* application developers wanting to deliver no compile updates and specific interfaces that are user editable

Links to check things out...
http://dot.kde.org/1087424515/ - recent article on the Dot
http://kde-apps.org/content/show.php?content=12865 - latest release

by Anonymous (not verified)

Dreaming or how much do you pay?

by superstoned (not verified)

I'd add
meta-data search capabilities (maybe using a kio-slave, and with ReiserFS4 compatibillity?)
and cairo/3d support.
maybe a sidebar/dasboard like tool (http://www.nat.org/dashboard/)
better integration of all communication tools (kmail/koptete etc)
support in konqi/kparts for also edditing of files (kword embedded in konqi, and being able to edit the file too, I'd love that. no more 5 kword windows open, just 1 konqi, with a filemanager, webpages, kword, all nicely in 1 window - a whole "projeKt" together. and of course I'd love being able to save the projekt! Gnome adds more windows for 1 task, KDE can integrate windows in 1... I think that's much better but its just me ;-) )

by Derek Kite (not verified)

>2. Speech synthesis and recognition

Kdeaccessibility has synthesis. There is a good free speech synthesis engine available which makes it possible.

Recognition is difficult. I would have thought that after 10 or 15 years of development there would be a good workable solution available, but there really isn't. A couple of years ago I talked to a fellow who worked for RCMP, where they have to transcribe data. He tried all the solutions, watched developments over a few years, but it didn't hit the sweet spot where it worked reliably for everyone. And the two big players seemed to have given up.

Derek

by Rayiner Hashem (not verified)

My KDE 4 wishlist:

1) Low latency, high-performance replacement for aRts.
2) A real option for a "minimalist" UI, that doesn't involve manually removing dozens of toolbar and context menu items.
3) Some esthetic touches, like a KIO download status box not completely covered with text, removal of some extraneous bevels here and there, and a less-ugly replacement for the Qt "disabled icon" effect.
4) Faster application startup.
5) Full Crystalization for icons that still don't have it (eg: Cervisia).

All in all, pretty minor stuff. That's how good KDE is already :)

by thibs (not verified)

I second this plus :
1) A improvement/replacement for aRts so that I could enjoy amarok without having 90% cpu load and sound skips.
2) An interface builder integrated to Kdevelop / so that everybody could finally easily (ie with very few knowledge) write applications for KDE.
3) Compatibility with XUL so that one could develop rich web applications that we could use/deploy both on the Mozilla and the KDE platform (we need that for this technology to gain momentum).
4) Modularity in the UI : possibility to have like different " UI schemas" for beginners (few options available), medium (reasonnable set of options) and expert (all options available). Maybe we could link that with Waldo's kiosk tool (to generate "UI schemas").
5) An global underlying layer that would manage user's data and would enable web services so that information (contacts, bookmarks, tasks...) can easily be shared / accessed between applications / machines / platforms.
6) Tight integration of Nomachine's NX technology (client & server) to have native thin client computing possibilities (Access to distant applications or sharing local applications...).
7) Better performance : memory footprint, cpu usage, launch time...
8) And as always : better usability.

KDE as a platform should try to follow freedesktop guidelines/implementations in order to follow the path toward a coherent Linux platform (so far there's no such Linux platform, there's Linux+Gnome platform, Linux+KDE, etc...).

My 2 cents...
Congratulations for the kde accomplished so far, it's just amazing !

thibs

by Anonymous (not verified)

> 2) An interface builder integrated to Kdevelop

Correct me, but isn't his not already happening in KDevelop 3.1?

by adymo (not verified)

This _is_ happening in 3.1 ;)

by ac (not verified)

My compliments on the new sounds for KDE3.3!!

check them out: http://www.artemio.net/projects/kdevibes/vibes/kde3.3/

by Waldo Bastian (not verified)

Nice proposals indeed...

by Alex (not verified)

I like the file selector proposal too, where can I vote for it?

by Alex (not verified)

Only place where I disagree is having the bookmarks in the left area instead of a global bookmark menu.

by Anonymous (not verified)

Very cool! I really like these ideas...

by fprog (not verified)

Seriously, I prefer bigger icons.

But the concept is good.

Home, Desktop, Documents, "Mounted drive", Recents, Bookmarks

It should be configurable, but a good way would be to have
a big bookmark icons that "expands" on the right side like this:

Recents and Bookmarks should be "directories" that can expand horizontally

+________+
|_________|>+___________________+
|_________|_|_My_Projects_________>
|_________|_|_favorite_link_123456___|
|_________|_|_favorite_link_abcdef____|
Bookmarks
+________+
|_________|
|_________|
|_________|

There should "really" be a Network / IO Slave entry,
so that novice users and even expert don't have to type cryptic URL
for CVS, FTP, SFTP, FISH, etc.

User could therefore "discover" IO Slave "naturally"
and see "wow I can do all those things" instead of
saying KDE cannot do this or that, because
they don't know that a IO slave exist.

+________+
|_________|>+________________________+
|_________|_|_FTP/SFTP______________>_+__________________+
|_________|_|_Fish_(SSH)______________|_|_[*]_Add_an_FTP_site__|
|_________|_|_CVS_/_CVS_over_SSH2___|_|_[D]_My_FTP_Project__>
_I/O_Slave__|_Search_for_new_I/O_slave__|_|_[~]_My_FTP_y_y_y_y__|
__________+________________________|_|_____________________|

and then by clicking on such link,
they could prompt a dialog and specify
host name, protocol, port number, encrypted or not, login/passwd,
password prompt, directory location, file name, etc.

instead of wondering how to do it or writting things like:

ftp://login:pw@x_x_x_x:21/dir/file_txt

There's the current CLI way and there should also be
the user friendly way_

CLI is faster if you know it,
GUI is faster if you don't.

Also, users could see once they "created their FTP shortcut",
how the CLI way is and learn it gradually.

i.e. If a user goes through the wizard/dialog after 10 times,
he will see that by chosing this and that options, he ends up with
ftp://login:pw@x.x.x.x:21/dir/file.txt

and then automatically learn how to do it without reading any manuals,
How to or asking for help by simply discovering how it works

This can be useful even for gurus who wish to learn
new CLI commands for new IO slaves without bothering
with reading manuals_ Just give them a dialog and the "end results"
Like I always say: "Give me a damn example and I'll handle the rest =)"

Just my 2 cents thinking

Fred

by ac (not verified)

FULL ACK!

Apart of the "KDE_Drum_Break.ogg" which IMHO sounds poor, the sounds are
generally very good, and they will enhance the KDE-experience and make it
feel very modern.

Good Work!