[kde] kover question

[gene heskett]

Greetings;

I just tried to use kover to generate an insert for a wedding dvd, and so 
far I've embedded the image to use, a .jpg saved from the kino snapshot 
function, and the title text to show over the image, but printing is not 
working.  Most of the time it send the job to cups where it hangs forever, 
so I kill the job & restart cupsd.  The one time it printed, it printed the 
whole page dead black, soaking ink plumb through the 24 lb paper.  At $30 
and change per tank of ink, that was disappointing to say the least.

Is this a known problem with Kover, and if so, is there another WYSIWYG 
insert composer that does work?

Thanks all.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


A lost ounce of gold may be found, a lost moment of time never.
___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

[kde] Re: KDE 4.6.0 and nvidia drivers

[John Woodhouse]

You don't say which kde version you are using. As far as web,mail and the 
editors go I haven't seen any problems at all with nouveau and 64bit kde 4.6.0. 
I did have one or two instances as you describe on 32bit. I installed the 
nvidia 
driver very soon after loading it though. For all I know that might have been 
the cause. Some of the lock up's seem to be down to something sleeping for far 
too long and maybe building up excesses in the queue can cause further 
problems. 
I now install no acpi and haven't noticed that sort of delay on either 32 or 
64bit. All I had on 32 then was missed mouse clicks or they seemed that way to 
me. Could be changes in kde.


On 64bit which I was reluctant to install due to past problems with finding 
64bit apps I installed 32bit Opera without any problem. My package manager 
complained but just downloaded a lot of 32bit libs. There does seem to be a 
very 
slight performance problem. New tabs and tab closings sometimes have a 
noticeable delay. I am very sensitive to spotting that sort of thing though.

As to nouveau I have the window fading which I find useful as I can read what's 
underneath but sizing a window with the mouse is a joke. It will track so far, 
then fall well behind and then stop. It catches up when the mouse button is 
released. Sort of OK but messy.


I'm just about to try and install the nvidia driver on 64bit.

On problems in this direction maybe with either driver I did see something on 
the web somewhere relating to "noflip" causing problems one way or the other. 
No 
interest at the time so no further info.

Opensuse 11.4 kde 4.6.0 - 6.

John



- Original Message 
From: A. Boggiano 
To: kde@mail.kde.org
Sent: Fri, 29 April, 2011 15:03:06
Subject: [kde] Re: KDE 4.6.0 and nvidia drivers

Il 29/04/2011 00:23, John Woodhouse ha scritto:


This is my story:
I'm using Fedora (now 14) on my HP HDX-18 with an nvidia GPU.
I don't want to use any closed driver since I need a very little 3D 
performances (I'm using only the simply KDE effects: "show all 
windows"...that's it!):so, I'm using the noveau driver.

Well, my machine freezes once a day: I can still ssh in it and reboot 
nicely but the X system doesn't respond! (I can't copy/paste here the 
Xorg.log but I can see noveau errors).
And yes, the freeze occours even if I don't enable the desktop effects.

>From a couple of days I'm using gnome (no desktop effects) and my work 
is running smootly.

This is *NOT* the solution, but, rigth now, it gives me some oxygen in 
order to try to investigate on the problem. I really don't know if the 
problem is noveau || kde || kwin || hw problem || bad luck, but this is 
my story!






___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

[kde] Re: Application launch files

[John Woodhouse]

Thanks Duncan. The lack of the facility was down to where I was looking for it.


I've degenerated into a subhuman and now mostly use the mouse. Comes from too 
many years of writing non pc software under windoze. The kit is usually a mix 
of 
what really should be run in msdos and windoze apps for emulators etc. Actually 
speed wise I don't think there is much difference providing editor keys are 
used. A windoze window however does usually fly a lot quicker if driven with 
 whatever. Dubious advantage really as most time is spent in it actually 
doing what ever it does. I try to give into change rather than fighting it as 
most change does have some advantages. - somewhere if you can find it.

John


- Original Message 
From: Duncan <1i5t5.dun...@cox.net>
To: kde@mail.kde.org
Sent: Sat, 30 April, 2011 13:22:43
Subject: [kde] Re: Application launch files

John Woodhouse posted on Sat, 30 Apr 2011 02:38:52 -0700 as excerpted:

> Thanks Duncan. I hope at some point a dev adds one of 3.x's nice feature
> where these were available for editing directly via a right click.

Referring to *.desktop files?  They are right-click editable, at least 
here.  Of course subject to permissions, but I have both a properties 
dialog with various tabs including *.desktop file specific tabs that allow 
editing, and an entry to open with kwrite (my primary kde editor, altho in 
practice I use mc/mcedit far more).

Also note that it's still possible to launch kmenuedit, either by context-
click on the menu plasmoid (classic, kickoff or lancelot) and choosing the 
menu editor function, or by launching kmenuedit directly, via krunner, 
konsole, or the like.

> I mostly use that to run something or the other as su but would also
> like to modify icons at times. For instance I currently have 2 dolphin
> icons on quick launch. One launches as su the other as per normal. Icons
> are identical.  I usually add an editor running as su as well. I prefer
> a version of Kate that remembers all of the files it's worked on for
> that.

I don't normally use quick-launch as I prefer keyboard shortcut launching, 
and indeed, had quite some difficulties transferring to kde4 because the 
kde3 multikey hotkeys quit working, and I tended to use a two-key 
sequence, one as my launcher prefix key (customized launch menu triggered 
by that key, if you will), the second to launch whatever app, and kde4's 
lack of multi-key hotkey support killed that for me.

After screwing with it for awhile, I realized that I could get essentially 
the same effect, by setting a kde hotkey to launch a custom launcher app, 
which then took one key and launched the app associated with it.  Well, 
I'm not a dev, but I'm decent at admin-level shell scripting, so I ended 
up creating a script that took one key, looked it up in a list, and 
launched the associated app.  I then setup a special konsole profile and 
special window rules for that konsole profile, and finally setup a kde 
hotkey to launch that script in my special konsole profile.

So I launch nearly everything I use routinely via hotkey sequence.  What I 
don't, I launch either from krunner, konsole, or the kickoff menu, and 
don't tend to have much use for an icon launcher plasmoid.  But that's 
just me.  The plasmoid's there for those who find it useful.

Anyway, quickly unlocking widgets, then adding a quicklaunch plasmoid so I 
can perform a few quick tests for this reply, it seems to have the 
expected context edit actions, etc.

Now what I *DO* see is that by default, it's using entries from the 
applications menu, which again by default, if they've not been edited 
there, are going to be the normal global system config entries.  As such, 
they won't be directly editable as your normal user.  That's to be 
expected as the global entries are system level and therefore need sysadmin 
level privs to edit.

However, if when adding a launcher, you type in the path to the executable 
directly (so /usr/bin/gwenview, for instance, instead of simply gwenview), 
then kde will create a NEW entry instead of using the existing menu entry 
(as it would had you simply typed the name, gwenview), and the NEW one 
will be fully editable. =:^)  If you check the properties, the desktop 
file itself will be found in something like (I've customized my setup and 
don't know the default any longer, so this is a guess) ~/.local/share/
applications/ instead of the system location, /usr/share/applications/.  
That's why it's fully editable.

> ;-) Seems quick launch is a panel now - but a panel for what.

??

Quick-launch is a plasmoid, a plasma widget.  It can be placed on the 
desktop (or other activity style), or in a panel, the same as any other 
plasmoid.  It's not a panel of its own, but can be placed in one if 
desired, or on the desktop if desired.

> As to security if some one can get in and make changes little matters
> really if it's a desktop file or something else. The important aspect is
> no back doors.

When

[kde] Re: Application launch files

[Duncan]

John Woodhouse posted on Sat, 30 Apr 2011 02:38:52 -0700 as excerpted:

> Thanks Duncan. I hope at some point a dev adds one of 3.x's nice feature
> where these were available for editing directly via a right click.

Referring to *.desktop files?  They are right-click editable, at least 
here.  Of course subject to permissions, but I have both a properties 
dialog with various tabs including *.desktop file specific tabs that allow 
editing, and an entry to open with kwrite (my primary kde editor, altho in 
practice I use mc/mcedit far more).

Also note that it's still possible to launch kmenuedit, either by context-
click on the menu plasmoid (classic, kickoff or lancelot) and choosing the 
menu editor function, or by launching kmenuedit directly, via krunner, 
konsole, or the like.

> I mostly use that to run something or the other as su but would also
> like to modify icons at times. For instance I currently have 2 dolphin
> icons on quick launch. One launches as su the other as per normal. Icons
> are identical.  I usually add an editor running as su as well. I prefer
> a version of Kate that remembers all of the files it's worked on for
> that.

I don't normally use quick-launch as I prefer keyboard shortcut launching, 
and indeed, had quite some difficulties transferring to kde4 because the 
kde3 multikey hotkeys quit working, and I tended to use a two-key 
sequence, one as my launcher prefix key (customized launch menu triggered 
by that key, if you will), the second to launch whatever app, and kde4's 
lack of multi-key hotkey support killed that for me.

After screwing with it for awhile, I realized that I could get essentially 
the same effect, by setting a kde hotkey to launch a custom launcher app, 
which then took one key and launched the app associated with it.  Well, 
I'm not a dev, but I'm decent at admin-level shell scripting, so I ended 
up creating a script that took one key, looked it up in a list, and 
launched the associated app.  I then setup a special konsole profile and 
special window rules for that konsole profile, and finally setup a kde 
hotkey to launch that script in my special konsole profile.

So I launch nearly everything I use routinely via hotkey sequence.  What I 
don't, I launch either from krunner, konsole, or the kickoff menu, and 
don't tend to have much use for an icon launcher plasmoid.  But that's 
just me.  The plasmoid's there for those who find it useful.

Anyway, quickly unlocking widgets, then adding a quicklaunch plasmoid so I 
can perform a few quick tests for this reply, it seems to have the 
expected context edit actions, etc.

Now what I *DO* see is that by default, it's using entries from the 
applications menu, which again by default, if they've not been edited 
there, are going to be the normal global system config entries.  As such, 
they won't be directly editable as your normal user.  That's to be 
expected as the global entries are system level and therefore need sysadmin 
level privs to edit.

However, if when adding a launcher, you type in the path to the executable 
directly (so /usr/bin/gwenview, for instance, instead of simply gwenview), 
then kde will create a NEW entry instead of using the existing menu entry 
(as it would had you simply typed the name, gwenview), and the NEW one 
will be fully editable. =:^)  If you check the properties, the desktop 
file itself will be found in something like (I've customized my setup and 
don't know the default any longer, so this is a guess) ~/.local/share/
applications/ instead of the system location, /usr/share/applications/.  
That's why it's fully editable.

> ;-) Seems quick launch is a panel now - but a panel for what.

??

Quick-launch is a plasmoid, a plasma widget.  It can be placed on the 
desktop (or other activity style), or in a panel, the same as any other 
plasmoid.  It's not a panel of its own, but can be placed in one if 
desired, or on the desktop if desired.

> As to security if some one can get in and make changes little matters
> really if it's a desktop file or something else. The important aspect is
> no back doors.

When the news came out, the point was that *.desktop files, much like MS 
Windows *.lnk (shortcut) files, allow the creator to choose both the icon 
and the command run -- without anything requiring a specific icon for a 
specific command.  Because, very similar to the MS *.lnk files, desktop 
environments of the time tended to hide the extension, an attack very 
similar to one used on MS Windows was possible.  It was quite easy to 
socially engineer a user into downloading and then clicking on a *.desktop 
file loaded with some sort of nefarious command, but identified with 
whatever icon was the default for something far less dangerous.

The result was some changes to the way things were handled.  I didn't 
follow all the details, but in certain cases, the system will now prompt 
whether you're sure you want to run , where it wouldn't, before, 
and I believe this has

[kde] Re: Application launch files

[John Woodhouse]

Thanks Duncan. I hope at some point a dev adds one of 3.x's nice feature where 
these were available for editing directly via a right click.


I mostly use that to run something or the other as su but would also like to 
modify icons at times. For instance I currently have 2 dolphin icons on quick 
launch. One launches as su the other as per normal. Icons are identical.  I 
usually add an editor running as su as well. I prefer a version of Kate that 
remembers all of the files it's worked on for that.

;-) Seems quick launch is a panel now - but a panel for what.

As to security if some one can get in and make changes little matters really if 
it's a desktop file or something else. The important aspect is no back doors. 
All systems are weak in some respect. I often wonder how long it will be before 
some on pretends to be a java update on windoze. That sort of thing could be 
applied to any system.

On html by the way I accidentally mailed with rich text enabled. This is not 
html and as far as I'm aware not open to the same amount of abuse. ;-) Could 
even look at it as an improvement over straight text really. Yahoo have even 
added it to it's groups recently. They are a very spam conscious outfit. Spam 
increases the amount of traffic they have to handle.

John


*.desktop files are normally simply plain-text files in the *.ini format 
MS Windows 3 made famous, sections denoted by 

[titles in brackets]
key="value pairs"

# blank lines ignored but normally separating sections, etc.

# The traditional *ix extension: comments starting with a hash

In the context of *.desktop files, each key=value line describes a 
particular bit of information about the service in question, its type 
(executable, service, etc), title in various languages, short and long 
descriptions, representative icon, whether it should be displayed in all 
*.desktop spec compatible environments or only one (kde only, for 
instance), etc.

Do note that because a *.desktop file can describe something to be 
executed with an icon and description that can be crafted to deceive the 
unwary user, there are potential security implications with allowing them 
to be placed just anywhere by anything, and executed without restriction.  
As a result, more modern *.desktop spec compatible environments often 
place some restriction on the execution of *.desktop files located in 
standard places such as the desktop directory, especially if they're user-
writable.

The cooperative specification is managed by freedesktop.org, which has the 
various versions available for viewing.

There are also tools available for verifying the format, etc. warning 
about missing quotes, semicolons, missing lines that should be found in a 
*.desktop file of a particular type, etc, and for managing installation of 
such files.  These tools are shipped in a package called 
"desktop-file-utils" or similar ("desktop-file-utils" is the name on 
Gentoo, which I use).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

___
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.