Slashdot Mirror

KDE.org has a nice interview with the president of TrollTech, Eirik Chambe Eng. Definitely worth a read!

KDE.org has a nice interview with the president of TrollTech, Eirik Chambe Eng. Definitely worth a read!

Better yet, you can even run KDE and GNOME through X11, in OS X.

Better yet, you can run KDE applications in OS X natively . It's still alpha and therefore pretty buggy, but it looks pretty good (KDE app icons in the Dock, for instance), and it's making progress. Konqueror seems to work reasonably well as a native app.

Canopy is also a major stakeholder in the SCO group
[...]
Do a little research and you'll find that Trolltech is going to answer any questions you may have regarding their connection to the Canopy Group, their board of directors, and the connections between same with a bland "no comment."


Well, Trolltech is not really secretive about their investors. Do a little research and you'll find this site. Out of the 9 parties and groups listed there, Canopy is number 7 and SCO number 9, with a combined share of about 5%. Now if you want to call that major... To me it would seem that Trolltech is majorly owned by it's employes.

With a little more research you even might find for axample this interview with the Trolltech President, where he talks about the Canopy investment:
-----
PF: Somebody mentioned that the Canopy Group & SCO owns some parts of Trolltech.

ME: Sorry, we don't have any influence on them.

PF: Do they have any influence on you?

ME: Not really. They have a 5.7% stake in Trolltech. Historically Canopy became an investor because we cooperated with Caldera. As you might know we made and delivered the graphic install, which was the first graphical install for Linux, for Caldera Linux. The Canopy Group as the main investor in Caldera was so impressed by the work we had done that they wanted to invest in Trolltech, to make sure that Trolltech could become a solid company that could continue to deliver software to the Linux community. It's pretty ironic to see what has happened historically after that of course. But they don't have any influence on Trolltech. Trolltech is employee-owned, 65% of the shares are owned by the employees and we control the business so they have a small stake in us and that is it.

PF: You haven't talk about this complicated with SCO on Linux

EE: The patent issue or the corporate issue?

PF: The thing that SCO is asking and preparing to sue everybody about some code they pretend they own in Linux.

EE: I can tell you that we do not support these actions from SCO. Trolltech in many ways is dependent on the success of Linux. We think Linux is a Good Thing. We support Linux in many ways. On the other hand everybody has the right to bring his case to court. In this case it is very strange that they have not pinpointed exactly where in the code there is a problem and we feel that if they really had a problem with this, they could have acted very differently in presenting this to the community. So again we do not support these actions.
------------------

Seems to be a quite complicated way to say 'no comment'.

Of course, he's theoretically wrong; the C standard actually does not exclude the possibility of preventing programs from doing bad things

• CCured
• Cyclone

Uh, they have already done it.
Yes, I like emacs better than vi, except I can't get friggin' real tabs...

I know I should not feed the trolls, but I can inform you that Xfce works very well on OpenBSD, and so does KDE. If only Firefox could render Slashdot properly, but that is not an OpenBSD problem ;-)

With Debian, today, I was told that if I wanted to do a dist-upgrade it would remove gnome and gnome-desktop. I've done an upgrade, and it allowed me to do that without removing gnome. [Now I need to find out why it was going to remove gnome...perhaps there's a good reason. But I can put that off until I find it out.])

The reason is explained here. (Just kidding. I'm not into flamewars on either side. I use Debian with wmaker myself.)

Apple's point, their key design idea, is that contextual menus should always be optional. There should, ideally, never be a feature that's in the right-click menu that's not accessible other places.

Gee, that seems to be a Microsoft idea, too, although they don't say that context menu items should always be available as menu bar items:

Avoid using a shortcut menu as the only way for a user to access a particular operation. At the same time, the items on a shortcut menu need not be limited only to commands that are included in drop-down menus. For example, you can include frequently used commands typically found in a secondary window, such as a specific property setting.

as Apple does in the Apple Human Interface Guidelines:

ever provide a contextual menu command that is not also accessible through the menu bar. Commands with keyboard shortcuts should be noted in the menu bar menu but not in the contextual menu. Use submenus with caution and keep them to one level.

The GNOME Human Interface Guidelines are somewhat less emphatic:

Since the user may not be aware of their presence, do not provide functions that are only accessible from popup menus unless you are confident that your target users will know how to use popup menus.

The KDE User Interface Guidelines don't have anything obvious on context/popup/shortcut menus.

The point is that if you use a BSD license, you are might as well call yourself an unpaid M$ employee: Chairman Gates can take your hard work and make millions selling it (of course, with the help of their legal hounds and rabid anti-open source public relations team).

If you want your code to accessible to the public FOREVER, license it under the GNU General Public License.

Secondly, you, the developer, CAN MAKE MONEY off using the GPL, by dual licensing your work (follow QT's example, the foundation of the KDE project).

If a big company does steal your work (e.g. inclused it in a proprietary, closed source product), sue their asses off and you may just become richer that you ever thought! You can't do that with the BSD license, now can you?

I'm presuming this is some sort of weird troll, moderated "informative" for some odd reason (seriously moderator, "informative"? What derf?)

Seriously, if you think the Microsoft development tools are far superior to anything else in the world, then I can only presume you've never used anything else in the world :).

I'm not a big dreamer. I just want ACL management in KDE and Gnome. This is great for offices getting off the Microsoft bandwagon.

http://bugs.gnome.org/show_bug.cgi?id=62817
http://bugs.kde.org/show_bug.cgi?id=6976

Hey, thanks, Juk looks pretty cool.

Check Konqueror. It is an integrated file manager, file viewer and Web/FTP browser for KDE. It's small, fast and full of features.

I haven't used them but I hear Kaffine, Amarok, and Juk are all very good players and more full-featured than XMMS.

I haven't used them but I hear Kaffine, Amarok, and Juk are all very good players and more full-featured than XMMS.

I use eSVN in KDE. Works okay for most of my SVN needs, but Cervisia wins, hands down. Probably the main reason I'm sticking with CVS for projects I have control over.

I manage the Tsukihime translation project, and there has been countless times it's saved our asses when someone edited something out of context and made no sense whatsoever. A quick look at a couple of revisons back allowed me to fix it in a few seconds, instead of wasting time contacting the original translator.

Kopete is an instant messenger supporting AIM, ICQ, MSN, Yahoo, Jabber, IRC, Novell GroupWise Messenger, Lotus SameTime*, and more. It is designed as a flexible and extensible multi-protocol system using plugins. (* in CVS)

There are plenty of usable window managers/desktop environments for UNIX.

You could also try KimDaBa here

Well, I don't think grandparent was a troll, but it was (is still) -5 uninformed. What you have to do to run kde is install it from the first CD (takes 5 minutes). Or, you can: pkg_add -r kde. AND you have a choice to install it from ports, compiling it for your specific hardware with optimizations. All it takes is one command: portinstall kde - if you want everything but the kitchen sync, or if you want a streamlined kde: portinstall kde-light.

learn more... it's not that difficult.

It doesn't care about the folder structure (you point it to a "root", like /mediafile/photos), has some pretty decent "Export to HTML album" and some rudimentary editing capabilities. (uses KIPI plugins).

You are probably already aware but gnome icons in OOo does not make it a Gnome project. Suse already shipped 9.2 with KDE-ified OOo. See http://dot.kde.org/1101482981/ http://linuxplanet.com/linuxplanet/reviews/5679/4/ screenshot3180/" http://www.openoffice.org/files/documents/159/1804 /NWF_icons_writer.jpg

Seriously, a lot of people are under the misconception that Aqua is a set of nifty-looking widgets. It's an interface standard for clean apps.

The Apple Human Interface Guidelines, to be precise.

I don't know whether all the issues you mention are described there, though - I didn't see anything that addressed the number of toolbar buttons, but it does give other recommendations for toolbars, so if by "a row of 20 NSButtons" you mean "something just using a row of NSButtons rather than using NSToolbar", doing the latter might give you toolbar behavior suggested in the Human Interface Guidelines that you wouldn't get with a row of NSButtons.

Now, the GNOME Human Interface Guidelines 2.0 does recommend not having too much in your toolbar in the section on toolbars:

Guidelines

• Place only the most commonly-used application functions on your toolbars. Don't just add buttons for every menu item.

The KDE User Interface Guidelines doesn't say anything about keeping the number of toolbar items down in its section on toolbars - in fact, it gives a list of items that should be in the toolbar if you have them in menus, so it might recommend increasing the number of toolbar items. (I think NSToolbar might give you a toolbar that can be customized, so you can have a set of buttons that the user could add to the toolbar if they wanted to, without having them in the default toolbar; the user can also remove items from a customizable toolbar.)

To add one more online HIG to the collection, the Windows Official Guidelines for User Interface Developers and Designers doesn't recommend, in its section on toolbars, that you keep the toolbar from being too cluttered, and its examples do have a number of buttons; it does recommend that you let the user configure it, at least.

Seriously, a lot of people are under the misconception that Aqua is a set of nifty-looking widgets. It's an interface standard for clean apps.

The Apple Human Interface Guidelines, to be precise.

I don't know whether all the issues you mention are described there, though - I didn't see anything that addressed the number of toolbar buttons, but it does give other recommendations for toolbars, so if by "a row of 20 NSButtons" you mean "something just using a row of NSButtons rather than using NSToolbar", doing the latter might give you toolbar behavior suggested in the Human Interface Guidelines that you wouldn't get with a row of NSButtons.

Now, the GNOME Human Interface Guidelines 2.0 does recommend not having too much in your toolbar in the section on toolbars:

Guidelines

• Place only the most commonly-used application functions on your toolbars. Don't just add buttons for every menu item.

The KDE User Interface Guidelines doesn't say anything about keeping the number of toolbar items down in its section on toolbars - in fact, it gives a list of items that should be in the toolbar if you have them in menus, so it might recommend increasing the number of toolbar items. (I think NSToolbar might give you a toolbar that can be customized, so you can have a set of buttons that the user could add to the toolbar if they wanted to, without having them in the default toolbar; the user can also remove items from a customizable toolbar.)

To add one more online HIG to the collection, the Windows Official Guidelines for User Interface Developers and Designers doesn't recommend, in its section on toolbars, that you keep the toolbar from being too cluttered, and its examples do have a number of buttons; it does recommend that you let the user configure it, at least.

The feature plan for 3.4 can be found here (taken from The Hunger's post)

The feature plan for 3.4 can be found here.

with a recent patch by Martin Koller the multicolumn view in konqueror will no longer truncate filenames. this was one of the most irritating aspects of the filemanager for years. thanks Martin!!! :)

check out this thread: http://bugs.kde.org/show_bug.cgi?id=42587

------- Additional Comment #18 From Martin Koller 2004-12-04 13:07 -------
CVS commit by mkoller:

BUG: 42587
GUI: The maximum text width used in konqis multi column view is now configurable in konqis appearance dialog. The default is 600 pixel, which should be enough to not wordwrap the files text.
Now the iconview determines the column width dynamically, so it's no longer fixed for all columns.

M +27 -6 kcontrol/konq/fontopts.cpp 1.59
M +1 -1 kcontrol/konq/fontopts.h 1.25
M +1 -0 libkonq/konq_defaults.h 1.29
M +30 -15 libkonq/konq_iconviewwidget.cc 1.306

2) For OOo/KDE binary see http://dot.kde.org/1101482981/

I'm sure there's a summary of the major changes somewhere, i just can't find it- good hunting

Odd... It was announced today!

http://www.kde.org/announcements/announce-3.4beta1 .php

If you're wondering, here is a feature plan for 4.0.

Enjoy

Re: the KDE 3.4 Compilation Requirements...

I would categorize the X Render Extension as recommended as opposed to optional. Aren't anti-aliased fonts a basic feature of any modern desktop environment?

I'll agree here with the software argument. When I buy a computer, I only factor in the price for bundled software that I would actually purchase. In the case of the Mac Mini, it's only Panther.

For solitaire on the Mac, I just used KPatience (kpat) which is available for a quick binary download through Fink Commander. It's a few more steps but I think it's one of the best solitaire programs out there.

Dear Anonymous Coward:

Have you read KDE'S Konqueror Changelog? No, just a lying rant!

http://konqueror.kde.org/news.php#itemKonqueror33R eleased

Wouldn't it make sense to build an office suite based upon something that works well with it?

Well, KOffice integrates so well into the KDE environment, it is incredible!

KOffice always felt more like AppleWorks than MS Office to me (not sure why). I, for one, would love to see Apple take this promising piece of software and use its underlying libraries as the basis of iWork.

Apple has been great about submitting KHTML changes back to the project tree. KOffice would benefit so much from Apple taking up their code.

Wouldn't it make sense to build an office suite based upon something that works well with it?

Well, KOffice integrates so well into the KDE environment, it is incredible!

KOffice always felt more like AppleWorks than MS Office to me (not sure why). I, for one, would love to see Apple take this promising piece of software and use its underlying libraries as the basis of iWork.

Apple has been great about submitting KHTML changes back to the project tree. KOffice would benefit so much from Apple taking up their code.

That's my bet. I'll expect you all to pay up when it happens...

http://docs.kde.org/en_GB/HEAD/kdesdk/umbrello/uml -basics.html is a good introduction to UML.

I'm planning to write an sftp "browser" front end in python

Sounds like a good project, but have you seen the SFTP KIOSlave? If you run KDE, you can read/write/browse SFTP transparently in KDE apps like Konqueror). CVS I don't use SFTP but I regularly edit files "live" over SCP (SSH) in KDevelop with nothing more than a File|Open, browse, edit, File|Save.

It's one of those features of KDE that almost makes the rest of its complexity worth it. (Fingers crossed until such transparency makes it to the kernel/filesystem level.)

If you need to figure out where in the sky those planets are, try kstars. It is one of the better planetarium-type apps out there.

Now if only the 'summer' skies over New Zealand would clear for a night, I can actually make use of my shiny new telescope.

--
Stellar Linux VPS Hosting

If you look at most OSS projects the only way to get code updates in is via the path mailing list.
A new poster will have and changes vigorously scrutinised, and even for the more regular project members there are quite a few people reading the list who will validate the patches whoever they are from.

Having said that trust levels are a bit mixed, the code of more frequent contributors tends to get glanced over causing bugs to needlessly be introduced.

The main problems I have found with OSS are:

Too few standards and integration, as a obvious example look at config files or command line arguments(what do I do for: help, version, verbose?). I think this is because the amount of organisation required to standardise software is quite high, and no one likes doing that kind of nitty-gritty work anyway.

Feature creep.

a: When a new version is released typically it has, stable functions, new slightly buggy functions and unsupported or beta functions that break 50% of the time. Commercial software would have dropped the broken functions regardless of how important they are.

As an example KDE document relations tool bar.

b: OSS never seems to stop being developed, why can libxyz or whatever be written and put on a 6 month update cycle to take account of any changes. If libxyz really needs all this extra functionality why mot make a separate library and agree some standards so everyone can use it? If it's still being hacked, do a re-write with a better architecture that doesn't require so many updates.

As an example, emerge -up world tells me ...
sys-libs/db, come on guy's freeze berky db and start working on a more advanced db instead of trying to hack improvements in.

1) Make filenames and command flags case-insensitive. The few cycles you spend doing case comparisons will quickly pale in comparison to the time savings you experience in tech support situations where a touch typist accidentally hits space too soon and types "emacS."

if you feel you'd like to use ambiguous, case-insensitive filenames, you should be using a UI which handles that re-mapping for you. i want my tools to know that file abcde is different from file ABCDE. Please don't "fix" that feature!

2) Several files that do not have extensions usually have some information about their default parser in line #1. Either parse it, or start using file extensions in *NIX.

But don't make this a part of UNIX, please! Sometimes you need to dig into a file's guts with a different tool than the one "associated" with that file type. Any sort of tight binding would be anathema to the flexibility and power that UNIX represents.

3) Start making UI's that only initially expose the 20% of the UI that 80% of people will use. There's no reason for a CD-burning package to have a checkbox on the main screen about verifying post-gap length for 99% of the people in the world.

Here's an example from GNOME's Human Interface Guidelines. If you find a gnome app that doesn't meet that spec, you should file a bug against it (or fix it, if you have the skills/tools to do so!). For KDE, you might want to read relevant sections from their User Interface Guidelines as well.

Let's clean up the UI so that people who want a Windows- or Mac-style interface can have it, yes! but please don't take that as a shortcoming of UNIX. If it's a problem, it's a problem of the GUI layers that have been built on top of it. But whatever you do, please please please don't sacrifice the flexibility and power that undergirds the whole system!

Why do you need GIMP for simple image manipulation? An image viewer that supports KIPI should do all what you need.

Except for some self-enlightened, 14 year old hypocrites on slashdot who cant code hello world, let alone a complex program like GIMP

And those that have never heard of virtual desktops maybe. Stay tuned though, Microsoft is scheduled to innovate that in its next release. ;)

The article at KDE.news

Heh, I was just reading the KDE news bar on the left, and this came up: KDE 3.4 Will Talk to You

The KDE Accessibility team is in the process of integrating speech synthesis into KDE. Not only does this mean better support for visually-impaired and speech-impaired users, but the new features should also prove for a fun desktop experience overall.

Seems very relevent!

There has recently been a a bunch of great work work on integrating speech synthesis software with KDE. You can read about it here: "KDE 3.4 Will Talk to You". It's not yet ready for completely blind users but the plan is for KDE 4.0 to support blind users. Plus, it's just cool to have your computer talk.

Very pertinent announcememt from this morning