A session can contain multiple start settings for a single app.
For example, it could contain: "start xemacs editing/etc/passwd on desktop 2, +200+120" and "start xemacs editing/etc/group minimized"
When you start Xemacs, which one should KDE chose? If you start Xemacs with a commandline argument specifying a file, should KDE ignore it and open the one specified in the session? Or both?
If the user starts Xemacs specifying geometry, should KDE override it? Is there a way to recognize if the geometry is specified or just a default?
Yes, a WM can do that. Of course that means it will get restored to the position in the next session (KWM does do that). The complaint is about position in the next INVOCATION of xemacs.
To do that, the app can do the job.
As a sidenote, ~/.xsession is the default session for xdm, so it would be bad to go changing it.
Yeah. I am one of the KDE representatives in the foundation. TT can't screw us (and they don't even want to screw us, of course).
In fact, I am much more confident about TT not screwing free software developers than I am about some free software fanatics screwing people who don't agree with their views on free software.
If only anonymous cowards would do it themselves!
on
KDE 2.0 in Action
·
· Score: 1
After all, "you" can do it just as easily as "they", and it is "you" who sais "it" would be a good thing.
If you want to use individual apps, use them. After you use enough KDE apps, the integration is so compelling you will want to use KDE versions instead of the alternatives.
For instance, it is cool being able to drop the URL of a.ps file into kghostview and have it read it. Or drop a file from ftp into a text editor and edit it.
Then, once you are running all those KDE apps, you will just use KDE. After all, the only "resident" parts in KDE 2 and kdesk and kicker, kicker being optional, and kdesk tiny.
It was just made to prove a point. Anyway: if someone is interested in writing a good C wrapper, ask me how. Putting work in it it can be made arbitrarily good (within the bounds of C, which are more painful than your message seems to imply)
The license is an agreement between the owner of the software (in this case the author) and the person who wants to use/distribute/modify the software (in this case you).
The owner doesn't have to follow the terms of the license because he is not a licensee, he is the licensor.
Look at it like this: remember when your dad told you "in my house you follow my rules"?
Now, do you think he also told that to himself?;-)
Do yourself a favour and use one of the excellent DB libraries written by Konstantin Knizhnik, that you can find at http://www.geocities.com/SiliconValley/Orchard/580 2/
These are *gems* and not nearly as known as they should
CFront and its ilk do *not* implement private members at the C level.
I am not saying it can't be done, I am saying that saying CFront did everything C++ requires in C is simply false.
Re:I think they are going in the wrong direction h
on
The Future of KDE
·
· Score: 1
Almost there:
1) Writing theme engines (called styles there) for Qt is a whole lot easier than doing it for GTK.
Why? OO design. You can *inherit* the, say, platinum style, and hack the widget that annoys you the most. On GTK the closest equivalent starts with "copy the sources for the GTKStep engine to that other directory".
2) Qt's user (non programmer) definable styles (the equivalent of GTK pixmap themes) are faster. One of the most used elements of those styles are gradients. In GTK you do them by stretching pixmaps, while in Qt you do them programatically (and actually, you do it from mosfet's cute designer), and they get rendered using optimized code instead of a general purpose pixmap routine.
Of course, if I am wrong, I invite anyone to correct me.
double clicks: Torben said yes, if my memory serves me. So...
running an xterm from minicli: that would suck:-) The whole point of minicli is that you *don't* load another program, so it's faster and memory slim:-(
I wrote a C binding for Qt. Extending it to KDE was trivial (just edit the headers into a simpler class description format for a script that actually did the binding).
How trivial? Well wrapping Qt, including writing the script mentioned above took a week, and I did it just to win a USENET argument.
Now, why did this binding never evolve further? The interest in C bindings for KDE and Qt seems to be limited to people that don't code, for the most part.
If you can write something like the machine generated C from CFront, you are not human.
Also, you are factually wrong: the generated C didn't implement private members, for example. Simply, the translator refused to generate the C to access the member that was supposed to be private, and spews an error *before* trying to implement it in C.
So, private members are feasible in C... as long as that means "I am a C programmer who can remember not to access that member!"
I mean, I could swear I saw a post just like this one when RHAD labs opened (what was it, a year ago?)
I suppose either your definition of "no time" is different from mine, or your subtle irony just passed over my head.
BTW: if you wanna count how many people work full time in KDE , you need to count some places besides MandrakeSoft (which anyways accounts for about 1/3rd of RHAD labs already anyhow?)
I am not going to address the reason for the slow or fast development of GNOME. Since I am not part of the GNOME project, I don't have enough knowledge.
However, I still remember an email from Miguel. Around september 1997? That said something like "we already have the gimp, mc which has a graphical version almost ready, VFS (and so on)".
So, at least on his eyes, KDE did *not* have a large lead at the time of GNOME creation.
Re:KDE had a lead of millions and millions of year
on
The Future of KDE
·
· Score: 1
I agree completely. I am after all a KDE developer and not impartial at all;-)
I was just replying (perhaps too subtly) to the claim that KDE had been in development for "years" before GNOME.
Slashdot Mirror
A session can contain multiple start settings for a single app.
/etc/passwd on desktop 2, +200+120" and "start xemacs editing /etc/group minimized"
:-)
For example, it could contain: "start xemacs editing
When you start Xemacs, which one should KDE chose?
If you start Xemacs with a commandline argument specifying a file, should KDE ignore it and open the one specified in the session? Or both?
If the user starts Xemacs specifying geometry, should KDE override it? Is there a way to recognize if the geometry is specified or just a default?
It's a lot trickier than it looks
Let's push this "contest" a bit further.
:-)
I can add another 5 lines of code and modify any arbitrary object in the page in any arbitrary way
using DOM.
Add that to your version
Yes, a WM can do that. Of course that means it
will get restored to the position in the next session (KWM does do that). The complaint is about position in the next INVOCATION of xemacs.
To do that, the app can do the job.
As a sidenote, ~/.xsession is the default session for xdm, so it would be bad to go changing it.
How is the WM supposed to remember your preferred position for XEmacs? How is it supposed to even know the window belongs to XEmacs?
In X, the application can remember its position. It can move itself there. It can do that regardless of WM. Why not ask XEmacs people to do it?
Yeah. I am one of the KDE representatives in the foundation. TT can't screw us (and they don't even want to screw us, of course).
In fact, I am much more confident about TT not screwing free software developers than I am about some free software fanatics screwing people who don't agree with their views on free software.
After all, "you" can do it just as easily as "they", and it is "you" who sais "it" would be a good thing.
If you want to use individual apps, use them. After you use enough KDE apps, the integration is so compelling you will want to use KDE versions instead of the alternatives.
.ps file into kghostview and have it read it. Or drop a file from ftp into a text editor and edit it.
For instance, it is cool being able to drop the URL of a
Then, once you are running all those KDE apps, you
will just use KDE. After all, the only "resident" parts in KDE 2 and kdesk and kicker, kicker being optional, and kdesk tiny.
1) Tar+gzip compresses about 10% more than DOS zip.
2) Tar+bzip2 compresses 20% better than DOS zip.
3) In KDE you don't need to use a tool to see what
is inside of a tarball. You just click on it.
4) If you fail to see the connection between a
tape archive and internet distribution, you are
more foolish than the average AC (and that's a
lot)
At least for me this is the first mention of KDE awareness in Afterstep. I got a similar mail about icewm.
If any WM has support for the KDE hints and stuff, let me know, and they will eventually get a headline in the KDE news page as well.
It was just made to prove a point.
Anyway: if someone is interested in writing a good C wrapper, ask me how. Putting work in it it can be made arbitrarily good (within the bounds of C, which are more painful than your message seems to imply)
The license is an agreement between the owner of the software (in this case the author) and the person who wants to use/distribute/modify the software (in this case you).
;-)
The owner doesn't have to follow the terms of the license because he is not a licensee, he is the licensor.
Look at it like this: remember when your dad told you "in my house you follow my rules"?
Now, do you think he also told that to himself?
C wrappers for C++ libraries are indeed possible.
I wrote one for Qt long ago.
Do yourself a favour and use one of the excellent DB libraries written by Konstantin Knizhnik, that you can find at http://www.geocities.com/SiliconValley/Orchard/580 2/
These are *gems* and not nearly as known as they should
CFront and its ilk do *not* implement private members at the C level.
I am not saying it can't be done, I am saying that saying CFront did everything C++ requires in C is simply false.
Almost there:
1) Writing theme engines (called styles there) for Qt is a whole lot easier than doing it for GTK.
Why? OO design. You can *inherit* the, say, platinum style, and hack the widget that annoys you the most. On GTK the closest equivalent starts with "copy the sources for the GTKStep engine to that other directory".
2) Qt's user (non programmer) definable styles (the equivalent of GTK pixmap themes) are faster. One of the most used elements of those styles are gradients. In GTK you do them by stretching pixmaps, while in Qt you do them programatically (and actually, you do it from mosfet's cute designer), and they get rendered using optimized code instead of a general purpose pixmap routine.
Of course, if I am wrong, I invite anyone to correct me.
find / -name "kcmdevmgr*" -exec rm {} \;
should do.
double clicks: Torben said yes, if my memory serves me. So...
:-) :-(
running an xterm from minicli: that would suck
The whole point of minicli is that you *don't* load another program, so it's faster and memory slim
I wrote a C binding for Qt. Extending it to KDE was trivial (just edit the headers into a simpler class description format for a script that actually did the binding).
How trivial? Well wrapping Qt, including writing the script mentioned above took a week, and I did it just to win a USENET argument.
Now, why did this binding never evolve further? The interest in C bindings for KDE and Qt seems to be limited to people that don't code, for the most part.
> Tell me why the reverse NIH argument couldn't be made against KDE's object model?
Well, because KDE's object model was started *before* baboon (or bonobo or however its called today)?
Isn't Gnumeric the only GNOME app of the ones you mention? Or have ABIWord and GIMP switched from pure GTK+ lately?
If you can write something like the machine generated C from CFront, you are not human.
Also, you are factually wrong: the generated C didn't implement private members, for example. Simply, the translator refused to generate the C to access the member that was supposed to be private, and spews an error *before* trying to implement it in C.
So, private members are feasible in C... as long as that means "I am a C programmer who can remember not to access that member!"
I mean, I could swear I saw a post just like this one when RHAD labs opened (what was it, a year ago?)
I suppose either your definition of "no time" is different from mine, or your subtle irony just passed over my head.
BTW: if you wanna count how many people work full time in KDE , you need to count some places besides MandrakeSoft (which anyways accounts for about 1/3rd of RHAD labs already anyhow?)
C++ doesn't enforce proper OO design. True.
C++ doesn't discourage proper OO design nearly as much as C does, either.
I am not going to address the reason for the slow or fast development of GNOME. Since I am not part of the GNOME project, I don't have enough knowledge.
However, I still remember an email from Miguel. Around september 1997? That said something like "we already have the gimp, mc which has a graphical version almost ready, VFS (and so on)".
So, at least on his eyes, KDE did *not* have a large lead at the time of GNOME creation.
I agree completely. I am after all a KDE developer and not impartial at all ;-)
I was just replying (perhaps too subtly) to the claim that KDE had been in development for "years" before GNOME.