Comments

Is there a good explaination of the problems with Qt 2.3.2? I just upgraded to KDE 2.2.2 with Qt 2.3.2, and I get periodic freeze ups, sometimes when I highlight a URL in the location bar. I've turned off Klipper, so that's not it. I'm making the current assumption that Qt is the culprit, and I'll upgrade in the next day or two.

it seems that some people get a little annoyed or confused when theDot doesn't post a story on the latest KC KDE issue immediately. this lag between release and appearance on theDot is due to the fact that i don't (usually) announce their release. Zack takes care of Linux Today for all the KC's and I really don't find much pleasure in hopping about from website to website posting announcements.

But all is not lost. Over time the KC KDE "project" has gained several contributors including Rob Kaper, Juergen Appel and Timothy Butler. Rob and Timothy will be looking after announcing KC KDE hither and yon from next week on. so theDot may even beat Linux Today at posting the newest KC KDE.

so everyone can stop bugging theDot people (and me) about it, m'kay? =)

Instead of people mailing me personally and complaining to me that KC KDE announcements are not posted on the dot first thing, why don't you instead write up something nice for the dot and *submit* it? That way as soon as an editor sees it, it can be approved. Good way of distributing the work, spreading the word, bringing liveliness to the dot, and everyone is happy. AFAIK, the Dot isn't intended to be a one-man show but rather wants to continue to be community-supported. We encourage contributions from all...

My own excuse is that lately I've been busy and rather absent from the Net, so by the time I notice a new KC and write up an announcement (if I have the time/courage), it's pretty late. Thankfully Dre took care of it already.

now could someone tell me, why don't they just put the arts-stuff in the kernel, remove esound and artsd, and use oss as the output for kde and all gnome-stuff? that would be one step to lowering the devision between kde and gnome... or what is I don't get?

aRts is far more poweful then just merged OSS streams. It has internal codec knowledge, MIDI capabilities, and all sort of nifty audio stuff. Plus, the mentioned module does not contain aRts, it just redirects OSS streams back to the normal (user-space) aRts server because artsdsp doesn't work with all apps.

I think the gnome people are going to kick out esd and use arts instead, if they haven't already done it. It'd be great if gnome and kde used the same sound deamon; I can live with gnome/kde apps looking and behaving differently, but they should be able to output sound at the same time.

i think arts still needs better documentation about things like network-transparent
audio (its in the faq but its wrong i think, i got it working by copying /tmp/mcop-blah over - instead of the suggested .mcoprc) and things like audio on a multi-user system. (or maybe i just failed to find the documentation)

Also, i have latency and stability problems with arts, but i guess thats a weird interaction problem on my system. (if i play a file, and start playing another file, the first 'play' stops for half a second and then plays on. i am running arts via artswrapper)

Actually, I don't need any esd apps so I haven't tried. It probably works. ;)

Speaking of network transparency, can you explain how you did it? I tried just a few hours ago to get it working, but without success. I use my laptop as an X terminal for my main computer and I'd like to have the sound redirected to the laptop too.

I can start artsd on the laptop, but how do I tell KDE on the main computer to use that artsd instead of starting a local one? I can't find any relevant settings in kcontrol (as you say, the manual/faq doesn't help much). I find no way of specifying address/port for the sound server.

well, i did the following:
i was logged in on box A with kde, and artsd was running so i had
a /tmp/mcop- directory
i just copied it over to box B, /tmp/mcop-
i also made sure box B and box A knew each other by short hostname (ping B and ping A worked)
and then it started to work. I wonder if there is a possiblity to do 'export SOUNDSERVER=host:user' or so, to make redirecting sound as easy as redirecting Xwindow apps.

ok, i get it... I was talking about the Linux-kernel since the issue was a patch for the linux-kernel.
all this is probably obsolete anyways, since, as I understand now, the kernel-module actually doesn't include arts, but would else be too discriminative towards solaris, freeBSD, etc. if the linux-version didn't need the artsd, whereas the others would? well anyways as I said, it's probably obsolete anyways...

The idea is this, instead of multiple desktops in the way its setup now, how
about having a desktop, a little arrow on on the far buttom right corner of
the desktop, when the user clicks this arrow, the icons on the desktop
change, nothing but the icons, It simply scrolls to the next list of icons.

This would not only make switching desktops faster, it willl make it more
practical because really alot of people dont want to have the entire desktop
itself change just so they can have more space.

Also with the taskbar, when someone wants to switch to taskbar 2, they click
an arrow, the original taskbar gets folded up into a verticle bar icon with
the words taskbar 1 from top to bottom and placed at the far left edge of
their bar.

Now i dont mean the entire taskbar changing, just the part where the open
programs which are running are shown, so this could be taskbar groupping in
the same way you have "task" grouping.

someone puts their mouse over a taskbar which is now just an bar on the new
taskbar itself, and a list of all the running task groups on that bar show
up, now a person can scroll through this list to find the programs they wish
to run.

Also I'd like a save feature almost like bookmarking on a web browser, and a
feature where someone can set a threshhold to how many tasks a taskbar will
open before automatically opening taskbar 2.

When taskbar 2 opens, the taskbar 1 is folded up and placed neatly in the
corner.

Another useful feature, would be a self organizing list, say you have a
powerful computer and have hundreds of programs open, when you fold the
taskbar up and put it out of view, and want to check through it there should
be options, such as the ability to search, an ability to list everything in
a specific order, such as browsers first, then music, then pictures etc etc.

This way if you want to find a specific task thats running on another
taskbar its only a click away, and the user can set this so its set for
their specific favorite tasks.

So they can switch from their browser on one taskbar, to their management
software on another.

I know alot of you wont really give ideas for enhancement much attention,
but hopefully you are better than the people on the gnome mailing lists who
dont really seem to listen to anyone who isnt a coder.

I believe sometimes it takes someone whos not a programmer to tell people
whats better for non programmers.

If you think any of my ideas are good, please discuss them, perhaps even
create some diagrams so you can see how it would look, and judge for
yourself if adding these features to kde is worth your time.

Also, I think it would be good to sometimes survey features you do add by
allowing people to give feedback on features from within KDE at the push of
a button."----End of Post

You see in my post i mentioned that I wanted to change the way multiple desktop works, this way there would be no way to "lose" track of your icons. Important Icons could just be locked or stuck or snapped into the backround of the desktop so whenever you click the arrow to get a blank desktop again your vital icons remain right there. Almost like bookmarking eh?

There are way too many "cool ideas" like these out there for KDE to implement them all. Mostly KDE just implements the ones that will make users feel at home on the desktop. If you want radical new features in a desktop, KDE is probably not the place to add them or ask for them. I think it is safe to say that these features will not be added into the main KDE releases, and it is not because they are bad ideas, or because KDE people don't listen to non-coders. It is because they are new and radical, and most users aren't used to them.

However, it sounds like what you want is a replacement for KDesktop, KWin, and Kicker. The beauty of KDE is that it is open source. All of these components can be modified if you want. All you need is some time and a willingness to learn.

>It is because they are new and radical, and most users aren't used to them.

That isn't true at all. Just look at konqueror, and give me another UI where you can install plugins into file manager/web browser to make it a printer manager, cd ripper, ssh client, terminal, and image thumbnailer? Seems pretty new and radical to me.

How about kicker? Windows and MacOS both have a definite lack of such a modular and extensible panel, though they both have rather similar concepts. Neither of those OSes have support for multiple desktops (well, possibly Mac OS X, but that was released after the feature was implemented in KDE), and if you're arguing for KDE attempting to accomodate the average user, the concept of multiple desktops doesn't fit.

I wouldn't implement your ideas (if it were up to me, and it isn't, so who can say) because the problems that the addressed by those methods have already been fixed. Searching is already implemented in the application-class taskbar organization option, your multiple taskbars is done in the form of multiple desktops. Making taskbars that automatically form new tabs as needed would look cool, but the organization would be nearly arbitrary. It's much better to give the user total control over grouping of their windows.

Konqueror's flexibility is a logical extension of Windows Explorer's ability to view web pages, ftp sites, local folders and network folders all in one interface. The availability of neat ioslaves is great, but almost the same thing is possible under Windows using shell extensions (though almost nobody uses this capability). KDE has simply made it easier and better. It's not radical, it is just a *very good* extension and generalization of an already-existing concept.

> How about kicker? Windows and MacOS both have a definite lack of such a modular and extensible panel, though they both have rather similar concepts.

Kicker is the place where KDE departs the most from the crowd, but even in Kicker many of the ideas are not radical at all. Dockapplets are not new, but KDE made them better. The system tray and the clock are directly from Windows, though they have been changed in appearence somewhat. The taskbar is almost exactly like other taskbars I've used.

> if you're arguing for KDE attempting to accomodate the average user, the concept of multiple desktops doesn't fit.

These ideas aren't new and radical though. They were well established long before KDE existed. Many of the people using KDE early on were not Windows converts but Unix coders, and they were used to multiple desktops and brought the idea with them. I'm not saying KDE always does what Windows does, I'm saying that KDE isn't a testing ground for radically new and different UI concepts like the ones thought up on the usability mailing list. KDE merges what is best about many different systems. KDE is a place for tested and well-liked UIs, not radically different and new UIs that may or may not be good.

I think there is a place for these radical new ideas. Berlin, maybe. Or a whole new project. Someone might even decide that they want to fork KDE and produce a different interface for it. I just don't think that these ideas belong in the main KDE development branch, which so many people use.

:: Konqueror's flexibility is a logical extension of Windows Explorer's ability to view web pages, ftp sites, local folders and network folders all in one interface.

No! It's a logical extension of the URI RFCs such as 2838 (which defines things like tv: for television). See my post from June 2000 on the subject ( http://lists.kde.org/?l=kde&m=96015237309542&w=2 ). Somewhere I have a long long list of useful KDE add ons that are a mix of kio_slaves and kparts.

URLs are *meant* to have context... context that allows the appropriate code to be executed. Long before IE existed, Mosaic was viewing http:. gopher: and ftp: (? It's been awhile) URLs built in. The next logical step is to add a plug in archetechture. Any time you have lots of add-ons, a modular archetecture makes sense - if you're running filters on an image (Photoshop), or spitting out formatted data to requests (Apache). Some are compiled in, some are loadable code.

It's also important to remember (and I worry this may get lost) that Konqueror is nothing but a framework, yes, but *all* correctly written KDE apps can access all the kio_slaves, and embed the same kparts that Konqueror uses. They can also expose themselves as kparts for other applications. It's this synergy (through not having to worry about depending on another corporation's code screwing you over) that makes open source great - it *can* depend on each other because were all on the same "team"... you create easily solved dependancies, not omes that require going out an buying Adobe Acrobat (the writer) because your billing software needs it (which occured last month to us).

It's late, and I'm starting to rant (okay, the entire post is a rant). Sorry about that - I've been wrangling buggy code for 12 hours... read the above with a grain of salt. :)

I don't think this is a good idea. I use multiple desktops to separate my applications, not my desktop icons. I don't really have many icons on my desktop. But I have usually many applications running and it is very nice to group them by desktop. And it really takes care also of the taskbar, as it only shows applications on current desktop. I think (real) multiple desktops are good. :-)

I always get lost with my desktops. Having more than one desktop is
confusing.

So what about the cube idea?

Render the desktop with OpenGL and make it like a virtual cube/box that
goes "into" your screen. Use two keys to rotate the cube, at least arround
the Y-Axis. This gives you four desktops. Let's make the sides of your cube
transparent and you can see windows currently on the back of the cube if you
move your windows out of the way. Cool, eh?

IMO, that's big-time overkill. For one thing, it would be annoyingly cycle-sucking to render, difficult to distinguish the reflection on your desktop of the desk behind you from actual windows, and almost completely advantageless. How is it that you lose track of your desktops? If you forget which windows are there, just use the Kicker pager preview, or the all-desktops window list on the left side of the taskbar applet.

To do my work I must have many applications running that do not all fit on the desktop, so i (have to) use multiple desktops. So i use the different desktops to get more screen space, not more icon space (i do not even have any icons on the desktop, the menu was invented for that).

While this may work for some people, i dont know ho wmany it would work for. I know there is no way i would use something like this.
Normally i use 6 desktops(3*2). I dont use them to keep icons seperate. I use 1 desktop for webbrowsers. one for aim and xmms. one for irc and sometimes a few shells. one for email and sometimes an editor. one for coding, uasualy xemacs and 2 shells. and one for other things, uasually kword.
It simply wouldnt work to have all these on 1 desktop. right now i have 12 windows open, frequently i have 20 open. that simply wouldnt work on one desktop. i have a total of 0 icons on my desktop. i do keep a panel down the side of the screen with launchers for the 5 apps i use most and a clock, and a tasklist at the bottom of the screen, i dont want anything more.
i think the people who would use your new idea are people who have recently switched to *nix from another OS, people who have not gotten into the multiple desktop paradigm.

Emergency lamp which generates the power it needs from a device attached to it.
Uses:
-> It can be carried any where
-> The power generated from the device attached can be used for other purpose also.
-> A slight alternation in the device attached will increase outcoming voltage

Emergency lamp which generates the power it needs from a device attached to it.
Uses:
-> It can be carried any where
-> The power generated from the device attached can be used for other purpose also.
-> A slight alternation in the device attached will increase outcoming voltage

The kernel is GPL'ed but kernel modules are explicitly not regarded as linking to the kernel, so it shouldn't be relevant.

KDE is GPL'ed according to rpm -qi kdebase.

Qt/Free is dual licensed, GPL and QPL, but for purposes of building or distributing KDE, it may have to be treated as GPL'ed.

aRts-oss, the kernel module, is only QPL'ed.

I think you can specify in your GPL'ed programs that there's an exception for linking to QPL'ed code, but aRts doesn't seem to have done this. Is it possible to write an aRts driver without linking to aRts?

It sounds like an awesome idea, but it seems best to get things all explicit before it becomes part of KDE and someone starts screaming GPL violation.

Why bother redirecting OSS streams to aRts anyway? Does anybody actually still own a sound card that doesn't do hardware mixing? A sound daemon is largely useless on modern systems, since /dev/dsp can be opened multiple times and the hardware can be used to mix the sound streams. By using aRts as a sound multiplexer, the KDE guys are shutting out a lot of people from using the advanced (reverb, special effects, HW mixing) the advanced features present in modern sound cards. IMHO, it would be better to seperate aRts into two parts. One part acting as a sound multiplexer (even then its pretty useless, ALSA, for example, does software mixing automatically if the HW doesn't support it) and another part acting as a multimedia framework. That would probably get rid of many of the latency problems people have with aRts, and wouldn't effect the common case (a few apps playing sounds concurrently, with no media being traded).

:: A sound daemon is largely useless on modern systems, since
:: /dev/dsp can be opened multiple times and the hardware

Yes, but what about things like network transparancy? What if there are multiple outputs?

:: By using aRts as a sound multiplexer, the KDE guys are
:: shutting out a lot of people from using the advanced
:: (reverb, special effects, HW mixing)

Why? The aRts system is an API... the hardware effects can be coded into the API, and you get the benefit of abstraction... you don't have to worry "What *if* the card doesn't support it", and you can take advantage of hardware features that are there (assuming that they are coded into aRts).

OpenGL will fall back to software support of features that the hardware dosen't support - and use the features that the hardware *does* support. aRts isn't there yet, but then, it's still young compared to OpenGL. To go by your reasoning, X, OpenGL, DirectX, and even video drivers are all useless... just access the hardware directly, and code each app for every piece of hardware you want to support.