List Info

Thread: Re: Re: Some notices due to kommander




Re: Re: Some notices due to kommander
country flaguser name
Germany
2008-03-02 07:28:12
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 <erickdewebdev.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
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander



_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

Re: Some notices due to kommander
country flaguser name
Romania
2008-03-03 02:08:48
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
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

Re: Some notices due to kommander
country flaguser name
United States
2008-03-03 11:19:41
On Sunday 02 March 2008 5:28:12 am Alexander Fischer wrote:
> 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.

The slots for completion relate to using KURL and presently
I don't see how to 
enable this, but I also don't see how to use this for
presenting my own list. 
This is another time it would help to know your widget and
purpose. The point 
is, I could create this functionality with scripting inside
Kommander, but 
why? If you are using a LineEdit switch to a ComboBox and
feed it changed 
lists on the fly. You can optionally make it editable. If
you're working with 
files use the dialog, and if you want file completion it is
in the old file 
selector widget.

If you want auto completion from within a TextEdit that is
another matter. You 
have to write code for that and I'm not sure that a simple
plugin could do 
that, but probably. With the Katepart you have all new
factors. First of all 
we wrote our own for Quanta, so I don't know if you will
find hooks for it 
but they would need to be DCOP hooks. I would check with a
running dialog 
dcop `dcop | grep kmdr` qt objects | grep complet -i
dcop `dcop | grep kmdr`"qt/path/to/object
functions"
dcop `dcop | grep kmdr`"qt/path/to/object
properties"
You can then use setProperty and property

BTW with your editor plugin example you posted I got 
qt/SimpleSampleTextEditor/edit/unnamed2(KateView,
0x6f16e0)/Kate Code 
Completion
However the functions and properties did not appear to be
very useful. If you 
look around some more you may find something more useful.
-- 
Eric Laffoon
Project Lead - kdewebdev module
_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )