a) Moritz is not the one who is writing about dropping X for Qt/E, so in any case he lacks the courage of someone else's convictions, which is a pretty smart thing to lack.
b) Check kdenox in KDE CVS.
Re:Woohoo! More Gnome than you can shake a stick a
on
Gnome 2.2 Released
·
· Score: 1
Uh, dude, you can use dcop from freaking shell scripts. And I am not joking. That is not C++ specific at all.
Well, you can do it like this. I will give a KDE example, because I am more familiar with it.
a) Start using KDE b) Find an app whose UI you think needs work c) Politely contact the app author, offering your help d) Don't barge in saying "hey, fool, this is how it's done" ala Eugenia Loli-Queru from osnews.com e) Try hacking a better UI through Qt designer (it's pretty easy, and if you are lucky, you won't even need to rebuild the app). f) Volunteer to take bugreports regarding UI for that app g) Don't propose changes that would involve huge refactoring and throwing away of code. If you do, noone will care, and you will be frustrated.
You obviously dont understand what KDE brings, therefore it is not surprising you deem it unworthy.
Sure, there are ftp libs and webdav libs.
But if Quanta was to use both, then Quanta would have to provide a UI for ftp, and a UI for webdav, and glue ode to link the UI to each library.
By using KDEs ioslaves, Quanta doesnt have to do nothing. Burcause the kioslaves produce a higuer level API, which abstracts the details of the mechanism.
Now, Quanta COULD write such a higher level API, but wouldnt that be just recreating kioslaves, only for each app? That makes no sense.
At a lower level, kioslaves use those libraries you mention, if necessary. So the code reuse at that level is also done.
And yes, if you dont use the KDE APIs, you dont integrate with KDE: And if KDE didnt provide APIs, then you dont integrate with KDE either, so what is the problem?
At least in the old days, Red Carpet made GNOME easier to install then KDE.
But right now, the "hard to install" KDE for redhat already exists and can be installed via apt-get doing two commands, less than a week afterits release.
Technically, it is KDE 3.1 for Red Hat 7.3, but I tried installing it in 8.0 and it works just fine. Set the apt sources as indicated on the page, follow the instructions, and it just works.
The only problem is that not all the packages are available yet, but libs/base/net/artwork are there and they seem to work just fine (except the xine-based video player, which seems to conflict with some freshrpm xinelibs I had).
Here is the URL: http://kde-redhat.sourceforge.net
Re:tired of desktops
on
Corporate KDE
·
· Score: 2, Informative
Of course, what you say would make a modicum of sense if KDE (or GNOME) had the goal of "put[ting] in place a gigantic, sluggish infrastructure and try to force everything to use the same libraries".
Since they don't, your comment is basically handwaving.
The goal of these desktops is to provide the infrastructure needed to make application development simpler, nicer.
For example: Suppose Quanta was not a KDE application. Now imagine a webmaster wants to use Quanta to edit pages on a website.
Since that is a very necessary feature, Quanta would have to implement some sort of ftp client. And perhaps also a scp/sftp client, a webdav client, and so on for every mechanism it wanted to support.
But... luckily Quanta *is* a KDE app. So, it got all that for free. And if tomorrow someone writes a mechanism to access any other remote site, Quanta will get it too.
Mind you, that is only one example of many, showing how infrastructure is sorely needed. Lack of it leads to poor applications.
Re:Is KDE trying to be Windows?
on
KDE 3.1 Released
·
· Score: 1
Ok, this is a stupid post because noone will read it, but I must say you have a weird way of thinking.
KDE currently can raise or not raise on click. YOU said that is not enough. Obviously, if we are to apply any logic to this, you want either only raise or only not-raise. Since what you want is not-raise, YOU are the one who wants something to be impossible.
As for the raise-on-resize, I asked you if you reported as a bug, and had no answer. Short: if you want it, report it. You will either get it, or be told you aint gonna get it. In either case, end of argument.
As for my reasons for switching to click-to-type: personal preference, and I wont say further, because all I gave you was a counterexample to your improbable claim.
Re:Is KDE trying to be Windows?
on
KDE 3.1 Released
·
· Score: 1
Ok. You have very special requirements for a very specific purpose, used by a tiny part of the userbase. Sorry, you don't get to call defaults.
You can suggest the users how they can get the behaviour you prefer, you can even make your installer change the behaviour. But you can not make everyone else get a default you prefer.
As for the focus-follow-mouse: Usually, if I try to force someone to do something he hates at first sight for a week, I must have a very good reason. Making an experiment is not one. And anyway, I don't need to. I used to use focus-follow-mouse in the fvwm times, and switched to click-to-focus around 1997. So, I am a clear example of such a person being possible to find.
Re:Is KDE trying to be Windows?
on
KDE 3.1 Released
·
· Score: 1
You don't see how "click on a dead area to rise" is less consistent? Well, let me show you: unless you personally are going to convince every app and toolkit writer to do it that way, some apps will rise, and some apps will not rise, because EVERY APP would have to implement that.
So, it seems the problem is not that kwin rises windows on click, but that kwin CAN raise windows on click?
If you know rising can be disabled, then what do you propose? That rising be impossible? Oh, yeah, we all should use YOUR preference.
If you want the cursor to match the focus, then use "focus strictly under mouse". I expect you to find it incredibly uncomfortable, though. I suppose that is another option you knew about but somehow forgot to mention. It is consistent, at least.
Did you report the thing about resizing as a bug?
As for your argument about click-to-focus being popular only because it was in windows, I could point you that no HCI study ever has shown that. Of course, I don't recall any showing the opposite either, but hey, you have your opinion, I have mine, just stating them is not going to change the other one's.
Also, it helps if you make claims that are at least plausible. You seem to be saying that you know no person who has tried focus-follows-mouse and preferred click-to-focus. I find that claim to be about as believable as stealth technology being donated by UFOs.
Re:Is KDE trying to be Windows?
on
KDE 3.1 Released
·
· Score: 1
Listen, just because there are ways to make things inconsistent now, that doesn't mean things should intentionally be made less consistent still. And yes, consistence is an important value in interface design, and if you don't like it, too bad. As for the toolkit deciding whether clicking on a "dead area" raises the window, that is even worse.
Predictable behaviour is important. Either all windows rise on click, or none does. And, surprisingly, Kwin has options about just what happens when you click on a window. Go the control panel, it is in the kwin config. module, in the actions tab. What you want is probably to set the "click on inactive window" action to something that doesn't have "raise" on it. How come you didn't notice that?
Mind you, I am not saying that this behaviour may not seem desirable to some, as it obviously does to you. It is just that you are likely to be a minority. So you will have to live with changing the default setting to what you like.
About the child windows: Yup, you are right. That only happens with modal dialogs. Have you reported it as a bug?
About focus and pointer warping: if it did what you want, a dozen people would whine about how pressing alt-tab makes the pointer walk all over the screen.
Kwin is not doing somethign wrong. Perhaps you want it not to give focus to popups? That can be done, and then it would be consistent, without weird behaviour.
As for your test with novices, what were they doing using focus-follows-mouse???? Usually people get extremely confused by it, so either:
a) They weren't novices b) They were using something they wouldn't normally use, so the point about warping doesn't mean much.
Re:Is KDE trying to be Windows?
on
KDE 3.1 Released
·
· Score: 1
Oh, yeah. Give the program the ability to raise itself instead of having the WM do it.
And then, when you click on some windows they rise, and others don't. Welcome to inconsistent city!
Rising "child windows" raises parent windows? In that case, I must have all sibling windows, because they all seem to raise or lower individually.
Warping pointers without the user requesting it is usually considered bad practice. The problem with focus-follow-mouse (we may as well use the common name for things) is that it goes along with popups about as well as vodka and matches.
BTW: KWM has not been part of KDE since version 2.0.
Configure a profile into kpf through dcop, but don't enable it. Then, when a conenction is made to kinetd's open socket *in the web server's defined port*, kinetd starts kpf, perhaps with a popup saying "Someone is downloading the vnc applet from you". Then, after the applet is downloaded, the profile is erased.
If kpf supported http simple auth, this can be refined somewhat.
You can create, start and stop a kpf instance through DCOP. SO, if the user chooses "share java applet" on the krfb config, you do it. And you close it down when krfb dies.
Nonsense. I can sell you the source of a program I write for a gazillion dollars and make it public domain the next day if I want, since I *own* the program, and you just license it.
In fact, I can license it to you for a gazillion dollars *after* I make it public domain, if I want.
a) Ctrl-A and Ctrl-E work just fine on KDE, so you should at least try to find an example that actually is related to the real world.
b) All standard global keybindings in KDE are configurable, and can be made into packages. So, if you feel KDE keybindings are bad, change them, put your config file in the web somewhere, with a ten line explanation on how to install it, and call it a day.
Slashdot Mirror
Use the kvim part, then eventually all text editing in all kde apps can be done with vi (no, it doesn't get so far yet).
And did you try pressing k in konqueror?
Any other places where you think this would be adequate?
web browsing:
;-)
Tabs in galeon are better.But I find the browsing experience in konqueror very pleasant, and quicker.
Multimedia:
The default UI for mplayer is text. In order to get the GTK one, you need to build gmplayer, which is optional.
IRC
Xchat is the definition of loaded. KSirc is pretty barebones, yet I find it nice, qick and simple.
News:
Well, I dropped the ball here, since I wrote the newsreader of KDE 1.x and never got it to work right, so knode had to start late in the game
Music:
Try Juk. Simple, extremely functional.
No, it means that you can have antialiased KDE on a sun display, or any display that lacks RENDER. At least that is what I understand.
Well, I would rate the odds of KDE dropping X as its primary platform, barring unforeseen unexpected developments, at between none and zero.
But for specific KDE apps, it can be done, if there is enough interest. Most of the KDE code doesn't require X at all.
Sure. But it sure beats not using the Zaurus because the keyboard is locked by the cradle, doesn't it?
Are you telling me you never heard of VNC servers?
r /
;-)
here is what 10 seconds of googling gave me:
http://community.zaurus.com/projects/fbvncserve
One would expect those who spend $300 on a gadget to actually try to use it
a) Moritz is not the one who is writing about dropping X for Qt/E, so in any case he lacks the courage of someone else's convictions, which is a pretty smart thing to lack.
b) Check kdenox in KDE CVS.
Uh, dude, you can use dcop from freaking shell scripts. And I am not joking. That is not C++ specific at all.
Well, you can do it like this. I will give a KDE example, because I am more familiar with it.
a) Start using KDE
b) Find an app whose UI you think needs work
c) Politely contact the app author, offering your help
d) Don't barge in saying "hey, fool, this is how it's done" ala Eugenia Loli-Queru from osnews.com
e) Try hacking a better UI through Qt designer (it's pretty easy, and if you are lucky, you won't even need to rebuild the app).
f) Volunteer to take bugreports regarding UI for that app
g) Don't propose changes that would involve huge refactoring and throwing away of code. If you do, noone will care, and you will be frustrated.
That is about it.
Yup. The Crystal SVG by Everaldo, and the Sphere by Vadim are KDE icon themes.
You obviously dont understand what KDE brings, therefore it is not surprising you deem it unworthy.
Sure, there are ftp libs and webdav libs.
But if Quanta was to use both, then Quanta would have to provide a UI for ftp, and a UI for webdav, and glue ode to link the UI to each library.
By using KDEs ioslaves, Quanta doesnt have to do nothing. Burcause the kioslaves produce a higuer level API, which abstracts the details of the mechanism.
Now, Quanta COULD write such a higher level API, but wouldnt that be just recreating kioslaves, only for each app? That makes no sense.
At a lower level, kioslaves use those libraries you mention, if necessary. So the code reuse at that level is also done.
And yes, if you dont use the KDE APIs, you dont integrate with KDE: And if KDE didnt provide APIs, then you dont integrate with KDE either, so what is the problem?
At least in the old days, Red Carpet made GNOME easier to install then KDE.
But right now, the "hard to install" KDE for redhat already exists and can be installed via apt-get doing two commands, less than a week afterits release.
Technically, it is KDE 3.1 for Red Hat 7.3, but I tried installing it in 8.0 and it works just fine. Set the apt sources as indicated on the page, follow the instructions, and it just works.
The only problem is that not all the packages are available yet, but libs/base/net/artwork are there and they seem to work just fine (except the xine-based video player, which seems to conflict with some freshrpm xinelibs I had).
Here is the URL: http://kde-redhat.sourceforge.net
Of course, what you say would make a modicum of sense if KDE (or GNOME) had the goal of "put[ting] in place a gigantic, sluggish infrastructure and try to force everything to use the same libraries".
Since they don't, your comment is basically handwaving.
The goal of these desktops is to provide the infrastructure needed to make application development simpler, nicer.
For example: Suppose Quanta was not a KDE application. Now imagine a webmaster wants to use Quanta to edit pages on a website.
Since that is a very necessary feature, Quanta would have to implement some sort of ftp client. And perhaps also a scp/sftp client, a webdav client, and so on for every mechanism it wanted to support.
But... luckily Quanta *is* a KDE app. So, it got all that for free. And if tomorrow someone writes a mechanism to access any other remote site, Quanta will get it too.
Mind you, that is only one example of many, showing how infrastructure is sorely needed. Lack of it leads to poor applications.
Ok, this is a stupid post because noone will read it, but I must say you have a weird way of thinking.
KDE currently can raise or not raise on click. YOU said that is not enough. Obviously, if we are to apply any logic to this, you want either only raise or only not-raise. Since what you want is not-raise, YOU are the one who wants something to be impossible.
As for the raise-on-resize, I asked you if you reported as a bug, and had no answer. Short: if you want it, report it. You will either get it, or be told you aint gonna get it. In either case, end of argument.
As for my reasons for switching to click-to-type: personal preference, and I wont say further, because all I gave you was a counterexample to your improbable claim.
Ok. You have very special requirements for a very specific purpose, used by a tiny part of the userbase. Sorry, you don't get to call defaults.
You can suggest the users how they can get the behaviour you prefer, you can even make your installer change the behaviour. But you can not make everyone else get a default you prefer.
As for the focus-follow-mouse: Usually, if I try to force someone to do something he hates at first sight for a week, I must have a very good reason. Making an experiment is not one. And anyway, I don't need to. I used to use focus-follow-mouse in the fvwm times, and switched to click-to-focus around 1997. So, I am a clear example of such a person being possible to find.
You don't see how "click on a dead area to rise" is less consistent? Well, let me show you: unless you personally are going to convince every app and toolkit writer to do it that way, some apps will rise, and some apps will not rise, because EVERY APP would have to implement that.
So, it seems the problem is not that kwin rises windows on click, but that kwin CAN raise windows on click?
If you know rising can be disabled, then what do you propose? That rising be impossible? Oh, yeah, we all should use YOUR preference.
If you want the cursor to match the focus, then use "focus strictly under mouse". I expect you to find it incredibly uncomfortable, though. I suppose that is another option you knew about but somehow forgot to mention. It is consistent, at least.
Did you report the thing about resizing as a bug?
As for your argument about click-to-focus being popular only because it was in windows, I could point you that no HCI study ever has shown that. Of course, I don't recall any showing the opposite either, but hey, you have your opinion, I have mine, just stating them is not going to change the other one's.
Also, it helps if you make claims that are at least plausible. You seem to be saying that you know no person who has tried focus-follows-mouse and preferred click-to-focus. I find that claim to be about as believable as stealth technology being donated by UFOs.
Listen, just because there are ways to make things inconsistent now, that doesn't mean things should intentionally be made less consistent still. And yes, consistence is an important value in interface design, and if you don't like it, too bad. As for the toolkit deciding whether clicking on a "dead area" raises the window, that is even worse.
Predictable behaviour is important. Either all windows rise on click, or none does. And, surprisingly, Kwin has options about just what happens when you click on a window. Go the control panel, it is in the kwin config. module, in the actions tab. What you want is probably to set the "click on inactive window" action to something that doesn't have "raise" on it. How come you didn't notice that?
Mind you, I am not saying that this behaviour may not seem desirable to some, as it obviously does to you. It is just that you are likely to be a minority. So you will have to live with changing the default setting to what you like.
About the child windows: Yup, you are right. That only happens with modal dialogs. Have you reported it as a bug?
About focus and pointer warping: if it did what you want, a dozen people would whine about how pressing alt-tab makes the pointer walk all over the screen.
Kwin is not doing somethign wrong. Perhaps you want it not to give focus to popups? That can be done, and then it would be consistent, without weird behaviour.
As for your test with novices, what were they doing using focus-follows-mouse???? Usually people get extremely confused by it, so either:
a) They weren't novices
b) They were using something they wouldn't normally use, so the point about warping doesn't mean much.
Oh, yeah. Give the program the ability to raise itself instead of having the WM do it.
And then, when you click on some windows they rise, and others don't. Welcome to inconsistent city!
Rising "child windows" raises parent windows? In that case, I must have all sibling windows, because they all seem to raise or lower individually.
Warping pointers without the user requesting it is usually considered bad practice. The problem with focus-follow-mouse (we may as well use the common name for things) is that it goes along with popups about as well as vodka and matches.
BTW: KWM has not been part of KDE since version 2.0.
Ok, then, third iteration ;-)
Configure a profile into kpf through dcop, but don't enable it. Then, when a conenction is made to kinetd's open socket *in the web server's defined port*, kinetd starts kpf, perhaps with a popup saying "Someone is downloading the vnc applet from you". Then, after the applet is downloaded, the profile is erased.
If kpf supported http simple auth, this can be refined somewhat.
Well, then contribute through a different mean.
I have a suggestion: contribute through money.
You have this kded thingie wating for the connection, right? Make it start and configure kpf.
You don't need to tell the user to do it.
And I need no solution, hackish or otherwise, I *can* put up a webpage
However, other users can not.
You can do it just using kpf.
You can create, start and stop a kpf instance through DCOP. SO, if the user chooses "share java applet" on the krfb config, you do it. And you close it down when krfb dies.
Nonsense. I can sell you the source of a program I write for a gazillion dollars and make it public domain the next day if I want, since I *own* the program, and you just license it.
In fact, I can license it to you for a gazillion dollars *after* I make it public domain, if I want.
One would also expect that someone that writes about the Qt license would actually have read it.
There is no OS restriction in the Qt license.
For example, I am doing a microwindows port. Microwindows runs just fine on DOS. You could use Qt on win32(with some effort) using it.
a) Ctrl-A and Ctrl-E work just fine on KDE, so you should at least try to find an example that actually is related to the real world.
b) All standard global keybindings in KDE are configurable, and can be made into packages. So, if you feel KDE keybindings are bad, change them, put your config file in the web somewhere, with a ten line explanation on how to install it, and call it a day.