Hello,
and thanks to you. Your response is a huge source of
inspiration
I did not know that the writeSetting() function writes into
the kommanderrc file. Because that it was in my case over
30kB big. Now, after clearing, it has only a size of 7kB. I
thought, every kmdr script has its own rc file or directory.
Fortunately my tables are static and the next release of
XSLrunner is going to make use of the file_write() and
file_read() functions. This is a promise
The "Open With..." dialog appears in Konqueror if
the user tries to open a file with an unknown extension or
file type. In my case I'd like to use it to set up a default
editor to open the xml and xsl files given by the user. The
input_openfile() is in real enough but my script is mainly
written for educational purposes and the dully users mainly
do not recognize that it is enough to write the name of the
editors executable in the input_openfile() dialog.
I will try to find a dcop call which initiates the dialog
but I am not optimistic.
The completion function would be usefull because I have a
very poor possibility to check xpath expressions in my
script and it would be cool to save the ones which are
usefull in the future or to control the learning effects of
the users and it is just a nice comfort feature. I will
check the slot functions.
In relation to the i18n aspect: Yes, there is a very new
article in the online docs which descripes the way to
extract po files and than to compile to po to mo files with
msgfmt. The point is:
If I just forget to give a keyboard shortcut tp a widget,
let run the kmdr2po script, translate and compile the po
file, all is fine.
But if I open the kmdr file just one more time with the
editor, the editor can (and mostly do) give the widget text
an "automatic" keyboard shortcut. After this
happens, the mo file is useless, because the executor can't
match the widget text anymore.
In "normal" written applications, this behaviour
works good, because the interface is modified seldom, but
not in Kommander because the code and the gui are edited in
the same environment and changes to the gui happen very
often.
The "Switch application language..." is available
in all KDE applications since version 3.5.7 or .8, even in
the kommander editor I don't
know how it works, but I don't think that it is a kpart
object because it is not available in KDEs control center.
I will even check the Kpart Plugin
Get well soon and thanks!
cu alex
-- Ursprüngl. Mitteil. --
Betreff: Re: [Kommander] Some notices due to kommander
Von: Eric Laffoon <eric kdewebdev.org>
Datum: 02.03.2008 08:36
Hi Alexander,
This looks like a great post. I'm sitting here with stopped
up ears after
standing out in the rain all day working my business... I'll
try to be
coherent for this email.
On Saturday 01 March 2008 8:38:11 am Alexander Fischer
wrote:
> Hello,
>
>
> first of all I'd like to say, that I love the new
parser offically
> introduced with KDE 3.5.9.
Thank you. It's been there for a while, but we finally shook
the bugs out and
added some nice touches. I really like the new indexed array
functions.
>
> Working on my little script XSLrunner (available at
kde-apps ), there
> came up some questions and notices to me, which I'd
like to summarise here:
I don't know, looks like something I typed, which is always
too long for a
summary.
>
> Using the new parser, I am no more dependent on using
bash and php in the
> very most situations. This is really excellent because
it limits the risk
> that system configuration differs on other systems.
Our thinking in offering it, and bash is slow. However you
can sheebang any
script in there too and it will defaul to the old parser in
that script which
makes it easy to access widgets.
>
> The documentation becomes better and better. This is
fantastic and was a
> big need.
It's nice to be appreciated after those late nights. Thanks
again for
noticing.
>
> Is there a way to use KDEs "Open With..."
dialog, maybe in a later version
>
You're talking what you get when you click on something in
konqeror? A lot of
things are possible, like calling an application with
parameters, using DCOP
or embedding a kde file part. It might help to know in what
context you want
to use this. BTW it could be built as a plugin and
distributed too.
> Is there a way to create a lineEdit-Object which
enables a history
> function like in a browsers adress bar.
I know we have this possible with files, I think in the file
selector. Also if
you look at the new slots function you will see several
completion functions
there. However I'm not certain how to utilize this within
Kommander. For one
thing you're going to need to specify what you're using to
complete with, and
not being completely familiar I'm not 100% certain
everything you need is
there, but you probably can do it. Andras might have a
better idea. Again, it
is absolutely possible to create a completion widget with
probably less than
20 lines of C++ using our new KDevelop template.
>
> I spent a bit of time in learning about i18n, but at
the moment I don't
> think the use of po files (with the i18n() function and
the kmdr2po.kmdr
> script) is the best possible solution. The point is
that doing it this way,
> I need an installer to use the compiled po files an
easy way. In my opinion
> this is nonsense because the most kommander scripts are
small and I loose
> one of the biggest advantages of kommander: the easy
portability. Isn't
> there for e.g. a xml based solution which refers to an
id (or the widget
> name) within the *kmdr files? In old versions of my
script I wrote the
> translatable texts in a ScriptObject which converted
these texts by user
> selection, but there was no way to access the names of
tabs, the "tooltip"
> or the "whatsthis" texts. Another problem, in
my opinion, is that I have to
> do the hole translation process with editing and
compiling the po file if
> there changed only one keyboard shortcut and this can
happen a lot of
> times. In my case the connection to the translation get
lost, if the editor
> inserts an & which happens automatically. Please
tell me, if there is a
> better way...
First of all I live in the US and am utterly clueless about
translations, not
to mention in awe of people speaking multiple languages
well. The po file
implementation in Kommander was done by Michal Rudlof, who
wrote much of
Kommander (including the parser) and happens to be one of
the Polish
translators. He ought to know what he's doing. As I
understand it there is
not need to do any compiling, but I'd have to dig to find
his how to. Is
there anything in the docs about it? If not, time for me to
look stupid. I
can search out his explanation if you like.
>
> Is there a way to access the dialog that is available
in KDE applications
> when choosing help in the menubar and then clicking
"Switch application
> language..."
I may have seen that once, before I tried to get everything
back to English.
If it is a standard KDE dialog it would need to be called as
a library. If we
need to do something like this we could look at making a
plugin. If it
happens to work as a KPart you can load it, but I doubt it
as I tried every
KPart I could, frequently giggling when I realized I could
do things like
check my mail in Kommander.
If this happens to be part of the running KDE it could also
work via DCOP.
>
> The writeSetting() function is still too slow to use it
in a wide maner and
> for all available settings in my script. I have 2
tables with 64 fields in
> each table and saving this costs approximately 10
seconds. How does this
> function work, is there a file for each setting?
Yikes! You're doing a not so good thing there. Of course we
hand you the high
explosives and say go play... The write setting was
developed to save
settings, but it saves everything to the main Kommander
settings file. So...
Doing what you describe is really hideous. It makes the file
really huge, and
if you're saving each field individually it's a very time
consuming exercise,
and from what you're saying that is what it sounds like.
Every call to
writeSetting() opens and edits that file, which by now must
be getting some
meat on it's bones.
First of all it is possible to read a table with Table1.text
which does
r0c0tr0c1tr0c2n
r1c0tr1c1tr1c2r
and so on. t is a tab and n is a new line. One easy way to
do it is like
this...
file_write("myfile", Table1.text)
Except it will probably end up in your home directory if you
ran the program
from the shell. To put it where your script lives use the
global for
Kommander dialog directory
file_write(_KDDIR+"/myfile", Table1.text)
Now you can read it back in. However you will find if you
had custom column
widths or row or column headers they will be gone with
Table1.setText(file_read(_KDDIR+"/myfile"))
Also if the file you read is smaller than your existing file
you may get
artifacts. If you delete the columns and rows and remake
them remember that
it seems to initialize with zero but end up with either one
more or one less
if you do it over again. I forget which, but I had to tweak
that. Another
alternative is to clear your known data area, for which I
keep a _datarows
type global many times so I know without having to check
every row for data.
for i=0 to rowcount do
for k=0 to colcount do
Table1.setCellText(i, k, "")
end
end
You can read in an data and write this way too. Say you have
table data you
want to manipulate before writing, or move around...
fdata = file_read(_KDDIR+"/myfile")
array_indexedFromString("a", fdata,
"n")
for i=0 to array_count("a")-1 do
array_indexedFromString("row", a[i])
//work with row of data here
end
Kommander does not support arrays of arrays, however it does
do tricks. While
it won't support
"a"+1 = "x"
it will support
array_indexedFromString("row"+i, a[i])
because "row"+i is an interpreted string, like
using variables to reference
widgets.
If you look through the included examples you'll see some
other neat tricks
like using key arrays in combos. Another thing I so is my
basic text data
file
==begin session file
info 0|user 1|timeout1 2|timeout2 3|remote 4
1
210000
300000
0
==end session file, begin kommander script
//read session info
fdata = file_read(_KDDIR+"/session")
array_indexedFromString("line", fdata,
"n")
array_fromString("map", str_replace(line[0],
"|", "n"))
_user = line[map["user"]]
What you see here is a creative use of separators. Line #0
is the map line. My
single constraint is I need to know what line I will be
writing when I
assemble the data file. So if I read a table, I figure the
number of lines,
then verify. What this does is give me access to any line
using the map. In
the case above the mapped variable "user"
corresponds to the second line,
which in a zero indexed array would be #1. With this I can
quickly write
multiple groups of data, then access it at will. I could
also use markers and
a while loop, but it's too easy to get in an endless loop
and get confused.
Kno9wing the line number and using a map means if one
section grows when I
write the file the map adjusts and it always references the
same line of
data, whatever the present stored value.
>
> Is there a way to make use of the, i don't now the
original name so i call
> it "embedding components", which are
available in konqueror (khtml,
> advanced editor component). I'm asking because this
would access syntax
> highlighting within a running kommander script when
previewing files.
If you use the KPart Plugin you can embed Kate. However if
you use the text
editor in Kommander I think you may be able to access the
highlighting with
slots. If you use the KPart loader your user would have to
have that plugin
installed to use it. With that you would use DCOP to control
it. While it is
a little work and there are some variables with object
naming (mulitple tabs
for instace) you would be able to do almost anything which
would be done with
Quanta, Kate, KDevelop or any other app using this client. I
would not tell
you that isn't a substantial amount of work.
Okay, I'm tired. There is a huge list of functions for the
TextEdit widget,
but (duh) it is the Kate part that offers this highlighting
using XML files
which of course I edited for this release. (duh-err) Sorry.
The KPart Loader is a small plugin available in the download
section of the
kommander site.
>
>
> Kommander rules!
>
> cu alex
>
Kommander is awesome. Check out some of the new demos I
posted on the site.
--
Eric Laffoon
Project Lead - kdewebdev module
_______________________________________________
Kommander mailing list
Kommander kdewebdev.org
http://mail.kdewebdev.org/mailman/listinfo/kommander
_______________________________________________
Kommander mailing list
Kommander kdewebdev.org
http://mail.kdewebdev.org/mailman/listinfo/kommander
|
Hi,
On Sunday 02 March 2008, Alexander Fischer wrote:
> The "Open With..." dialog appears in
Konqueror if the user tries to
> open a file with an unknown extension or file type. In
my case I'd
> like to use it to set up a default editor to open the
xml and xsl
> files given by the user.
I don't think this is possible now with Kommander, unless
you write some
kind of plugins that returns to you the Open With... list
for a file.
The plugin should be written in C++ of course.
> In relation to the i18n aspect: Yes, there is a very
new article in
> the online docs which descripes the way to extract po
files and than
> to compile to po to mo files with msgfmt. The point is:
If I just
> forget to give a keyboard shortcut tp a widget, let run
the kmdr2po
> script, translate and compile the po file, all is fine.
But if I open
> the kmdr file just one more time with the editor, the
editor can (and
> mostly do) give the widget text an
"automatic" keyboard shortcut.
> After this happens, the mo file is useless, because the
executor
> can't match the widget text anymore. In
"normal" written
> applications, this behaviour works good, because the
interface is
> modified seldom, but not in Kommander because the code
and the gui
> are edited in the same environment and changes to the
gui happen very
> often.
That's true, and unfortunate. But this is how the *whole*
KDE is
translated (and this is the reason why the current method
was chosen
for Kommander). Right now for .kmdr files shipped with KDE
(like the
ones included in Quanta) there is no need for separate
translation
tool, the translator won't even notice if the string comes
from a C++
application or a Kommander dialog. And this is good.
For your problem, there is a fixuifiles script (I think it
is in the
kdesdk module), which removes the shortcut strings added by
Qt
Designer. You might give a try to it, maybe it helps for
Kommander
dialogs as well.
> The "Switch application language..." is
available in all KDE
> applications since version 3.5.7 or .8, even in the
kommander editor
> I don't
know how it works, but I don't think that it is a kpart
> object because it is not available in KDEs control
center.
You can anytime start a KDE application in a different
language from the
command line. Like:
KDE_LANG=hu_HU kate
should run Kate in Hungarian if the Hungarian translation
files are
installed.
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org
_______________________________________________
Kommander mailing list
Kommander kdewebdev.org
http://mail.kdewebdev.org/mailman/listinfo/kommander
|