logicaldesktop-general Mailing List for Logical Desktop

Status: Alpha

Brought to you by: seguso

logicaldesktop-general — For technical and conceptual discussions

You can subscribe to this list here.

2004	_Jan	_Feb	_Mar	_Apr	_May	_Jun	_Jul (35)	_Aug (4)	_Sep (1)	_Oct	_Nov	_Dec

Flat | Threaded

1 2 > >> (Page 1 of 2)

[Logicaldesktop-general] Introducing OneFinger - the graphical shell

From: Maurizio C. <seg...@ti...> - 2004-09-16 15:29:58

hello boys,

here is a surprise for you:

http://onefinger.sf.net

Almost like logicaldesktop, except that is is usable. :-)

Take care everyone!

-----
Regards, 
Maurizio Colucci
http://onefinger.sourceforge.net

[Logicaldesktop-general] Recent windows applet ready

From: Maurizio C. <seg...@ti...> - 2004-08-27 13:07:00

Hi there,

There is a new logicaldesktop module called "windowlist", which is a kicker 
applet meant to replace the standard KDE taskbar. 

The feature is that it sorts the window by recent usage, like ALT+TAB, making 
it the ideal choice when you keep many windows open at a time.

cvs -d:pserver:ano...@cv...:/cvsroot/logicaldesktop co windowlist 


Enjoy. :-)

Written in C, requires kde-devel to compile.
-- 
Maurizio Colucci
http://logicaldesktop.sourceforge.net

Re: [Logicaldesktop-general] lv translation, suggestions

From: Maurizio C. <seg...@ti...> - 2004-08-23 19:45:06

On Monday 23 August 2004 21:37, P=C4=93teris Caune wrote:
> I tried the program, and i like it.

That's good news!

> I made a Latvian .po as instructed, but there are problems with
> encoding. All Latvian special characters are shown incorrectly. I
> double-checked the file is saved in utf-8, tried several other encodings
> (got make complaining about incorrect multibyte sequences). Every
> special character is shown as 2 random characters, so, I guess, the
> program is trying to use some ISO encoding instead of utf-8.
> lv.po is attached.

Thank you very much. Unfortunately I don't know anything about the code tha=
t=20
deals with internationalization. That was added by Thomas. Let's hope he is=
=20
at home :-)

> Suggestion - for this program to become really useful for me, it needs
> handy shortcut keys (there are 100+ keys on keyboard, about 6 - 10 of
> them are used right now) and an easy way to find them out - tooltips :)

I am aware of that, but first there are very pressing issues to deal with.=
=20

I am currently adding a task list (like ALT+TAB in KDE, but usable with the=
=20
mouse).=20

Then I'll have to convert the program to a panel applet, otherwise the task=
=20
list is useless.

Then I'll have to find a way to detect devices.

And I don't have much time currently... :-}

cheers

=2D-=20
Maurizio Colucci
http://logicaldesktop.sourceforge.net

[Logicaldesktop-general] lv translation, suggestions

From: <cu...@na...> - 2004-08-23 19:37:54

Attachments: lv.po

I tried the program, and i like it.
I made a Latvian .po as instructed, but there are problems with 
encoding. All Latvian special characters are shown incorrectly. I 
double-checked the file is saved in utf-8, tried several other encodings 
(got make complaining about incorrect multibyte sequences). Every 
special character is shown as 2 random characters, so, I guess, the 
program is trying to use some ISO encoding instead of utf-8.
lv.po is attached.

Suggestion - for this program to become really useful for me, it needs 
handy shortcut keys (there are 100+ keys on keyboard, about 6 - 10 of 
them are used right now) and an easy way to find them out - tooltips :)

Peeteris Caune

[Logicaldesktop-general] Any idea how to...

From: Maurizio C. <seg...@ti...> - 2004-08-19 16:56:27

Hello people,
I hope your vacation has been (or is being) good ;-)

I think it's important for LD to have a taskbar like the one in kicker or 
gnome-panel.

I think I will add a button "recent windows", which brings a list of windows 
sorted by last access time (like ALT+TAB).

But I don't know where to start... should I ask the window manager? Or X 
itself?

If you have a clue... 

cheers

-- 
Maurizio Colucci
http://logicaldesktop.sourceforge.net

[Logicaldesktop-general] Some reflections

From: Maurizio C. <seg...@ti...> - 2004-07-18 21:14:26

=46rom the TODO file:

Using .desktop files
=2D-------------------

 With the library "kio.KConfig", we can enumerate the installed
 programs, and read their name, icon, executable file, and the mime
 types managed by each program.

 Additionally, with the library "kdecore.KDesktopFile", we can parse
 .desktop files in kde/share/apps/konqueror/servicemenus, and discover
 the additional actions supported by the programs --- the actions that
 appear in konqueror "Actions" menu (e.g. "create data cd with k3b").

 Now, how can LD use those informations? First of all, it is important
 to understand that LD must also display informations (icon, verbs...)
 about programs that are NOT installed! So it cannot rely on .desktop
 files completely, because .desktop files are only available for
 installed programs. LD still needs an internal db of programs and
 their capabilities.

 Does this mean .desktop files are completely useless for LD? This
 would only be true if adding support for a program did not cost us
 anything. But it does cost, so our program database is neither
 complete nor accurate.

 1. there are still many programs LD doesn't know;

 2. thare are many programs for which LD has wrong informations
    (e.g. it does not know all the mimetypes they manage; it has an old
    icon; it does not know all the actions they support).

 3. there are many unimplemented verbs.

 The idea is to use the .desktop files where present, to solve those
 problems:

  1. add some kind of basic support for programs that are installed
     but unknown to LD;

  2. refine informations for programs that are installed and known to
     LD;

  3. automatically read the implementation for verbs from the .desktop
     files.

Unfortunately, there are many subtle problems with these points.

Problem: UNKOWN PROGRAMS CANNOT OPEN KNOWN FILES. Suppose in LD there
is a verb "play audio", which requires an mp3 or an ogg. Suppose LD
knows the programs "xmms" and "totem" that support that verb. Suppose
now LD finds a new program "kaffeine", whose .desktop file says it can
open mp3 and ogg files, but specifies no action. LD knows nothing
about what the program will do with the mp3 file: will it play them?
Will it encode/decode them?  So LD cannot add kaffeine to the programs
that support "play audio". And it cannot simply add a generic verb
"open with", because it would conflict with "play audio": suppose the
user selects an mp3. He sees the verbs "play audio" and "open with",
which is too ugly.  Conclusion: LD cannot allow unknown programs to
open KNOWN files. --------------- Even if the program declares an
action, things don't change: suppose the same as before, but this time
kaffeine has a .desktop file that not only specifies the mimetypes mp3
and ogg, but also declares an action "play sound" --- and says the
action can be applied to mp3 files. Unfortunately LD cannot understand
that the meaning of the actions is the same as "play audio", so it
cannot simply add kaffeine to the programs that support "Play audio".
LD cannot add a new action "play sound" either: this would cause the
same problem as before: suppose the user selects an mp3: then he will
see two verbs: "Play audio" and "Play sound". This must not
happen. --------------------What about unknown programs that manage
files of any type? Like krename? Or any directory, like kdirstat? we
can't accept these programs either. Suppose we find a program that can
manage any file, like krename. LD cannot tell that krename renames
files: it can only add a verb "open with krename" or whatever action
krename declares. But this is not enough: if the user clicks "rename
file", krename should appear in the list, but it does not. This cannot
happen.


Problem: UNKNOWN PROGRAMS THAT DON'T MANAGE FILES CANNOT BE
ADDED. Suppose LD finds an unknown program called "switcher" that
actually turns off your computer. Even if "switcher" supplies an
action "turn off computer", LD cannot tell what switcher does. So it
cannot add it to the right verb ---which is "Power off". If LD simply
added the verb "Switch off computer", and the user selected "power
off", he would not see switcher, which is an error.


Problem. DESKTOP FILES CANNOT BE USED TO ASSOCIATE KNOWN MIMETYPES TO
A KNOWN PROGRAM. Suppose LD thinks that xmms can manage only mp3
files, but in the .desktop file for xmms it's written that xmms can
manage ogms too. Suppose ogms are known by LD (i.e. some verb requires
ogm). Then, unfortunately, ogms cannot be added to the verb "play
audio", even xmms supports that verb, because LD does not know WHAT
xmms can do to ogm files; in theory it could even do something that
completely different from "play"!

Example. UNKNOWN PROGRAMS THAT MANAGE UNKNOWN FILES CAN BE ADDED. If
there is a program (oowriter) that manages an unknown file (sxw), LD
can add a verb "open sxw" and associate oowriter (and any other
program that manages sxw) to it. There is no conflict with that. Also
it oowriter manages some known files, it is no problem either:
oowriter will only be usable to open sxw files. You can't use it to
open known files, for reasons explained earlier.

Example. DESKTOP FILES CAN BE USED TO ASSOCIATE UNKNOWN MIMETYPES TO A
KNOWN PROGRAM. Suppose LD knows oowriter, but only knows it can manage
sxw files. LD doesn't know oowriter can manage DOC files. In that
case, if DOC is an unknown file, LD can create a verb "open
DOC". Unfortunately, if DOC is known (i.e. there is already a verb
that requires DOC files), nothing can be done, for reasons explained
earlier.

Example. DESKTOP FILES ALLOW US NOT TO WRITE THE SEMANTICS
ANYMORE. For example, now LD has a semantics for "Burn data cd" has an
internal switch that does "k3b --datacd <files>" or "xcdroast
=2D-data-cd <files>" depending on the program chosen by the user. This
will not be necessary anymore. All the LD programmer must do is to
associate the LD verb "Burn data CD" with the actions {"Create data cd
with k3b", "create cd with xcdroast"}, whose commandline is specified
in .desktop files for k3b and xcdroast.

Re: [Logicaldesktop-general] Optimizations

From: Maurizio C. <seg...@ti...> - 2004-07-17 15:34:33

On Friday 09 July 2004 15:43, Maurizio Colucci wrote:
>> Second to consider, for the future, using a python compiler to produce
>> faster code.

I tried logical desktop with psyco, and it runs about 10 times _slower_! Does 
anyone know what could be happening?

Maurizio

Re: [Logicaldesktop-general] Technology switch?

From: Maurizio C. <seg...@ti...> - 2004-07-11 09:04:57

On Sunday 11 July 2004 01:26, Lawrence Oluyede wrote:
> > Well, functional languages are easier to read IMO. They are more
> > declarative. You have a better comprehension of how the data is
> > transformed.
>
> Easier only if you have ever used a functional programming language
> before in a serious way (I don't). Anyway, for the final user it
> doesn't matter

You 're right...
>
> > First of all, we don't need much speed, it's already ok, except very long
> > folders. Anyway, python is dynamically typed, so, even if compiled, must
> > do more checks than mono at runtime.
>
> Python is strongly and dinamically typed so there's not a difference
> a-priori,

Well, Python must check the type at runtime, mono must not. Anyway the impact 
of this may be irrelevant, if that's what you mean.

> cause the speedness of a program doesn't depend only on 
> that...  Anyway it's up to you :) 

For fun, maybe I'll add an independent version which uses mono.

Maybe :-)

Mau

Re: [Logicaldesktop-general] Technology switch?

From: Lawrence O. <l.o...@gm...> - 2004-07-11 08:26:43

> Well, functional languages are easier to read IMO. They are more declarative.
> You have a better comprehension of how the data is transformed.

Easier only if you have ever used a functional programming language
before in a serious way (I don't). Anyway, for the final user it
doesn't matter

> First of all, we don't need much speed, it's already ok, except very long
> folders. Anyway, python is dynamically typed, so, even if compiled, must do
> more checks than mono at runtime. 

Python is strongly and dinamically typed so there's not a difference
a-priori, cause the speedness of a program doesn't depend only on
that... Anyway it's up to you :)

Re: [Logicaldesktop-general] Technology switch?

From: Maurizio C. <seg...@ti...> - 2004-07-10 21:44:57

On Saturday 10 July 2004 13:25, Lawrence Oluyede wrote:
> > I am seriously considering rewriting the app in Nemerle + Mono + Gtksharp
> > + gtkhtml-sharp.
> >This allows us to integrate into gnome-panel, have integrated
> > web browsing, write our own ListBox widget, all without touching C++ or
> > C. The nemerle code would be cleaner and faster than python.
>
> Mmm using Mono and so on it's cool but why Nemerle? Do you prefer
> functional languages? (I know the answer :P). 

Well, functional languages are easier to read IMO. They are more declarative. 
You have a better comprehension of how the data is transformed.

> Anyway, why you think it will be "faster" ?

First of all, we don't need much speed, it's already ok, except very long 
folders. Anyway, python is dynamically typed, so, even if compiled, must do 
more checks than mono at runtime. The price you pay for in mono for the 
additional execution speed is that you spend more time coding: you have to 
declare the types of your variables (yes, type inference is a complete farce 
IMO).

Mau

Re: [Logicaldesktop-general] Technology switch?

From: Lawrence O. <l.o...@gm...> - 2004-07-10 20:25:09

> I am seriously considering rewriting the app in Nemerle + Mono + Gtksharp +
> gtkhtml-sharp.
>This allows us to integrate into gnome-panel, have integrated
> web browsing, write our own ListBox widget, all without touching C++ or C.
> The nemerle code would be cleaner and faster than python.

Mmm using Mono and so on it's cool but why Nemerle? Do you prefer
functional languages? (I know the answer :P). Anyway, why you think it
will be "faster" ?

[Logicaldesktop-general] Technology switch?

From: Maurizio C. <seg...@ti...> - 2004-07-10 17:20:35

I am seriously considering rewriting the app in Nemerle + Mono + Gtksharp + 
gtkhtml-sharp. This allows us to integrate into gnome-panel, have integrated 
web browsing, write our own ListBox widget, all without touching C++ or C. 
The nemerle code would be cleaner and faster than python.

The problem is I can't write the MyListBox widget in gtk. It is just too 
difficult for me; with Qt it was very easy. Maybe in the future... or if 
someone helps. :-)

Mau

Re: [Logicaldesktop-general] Re: About the scrolling buttons

From: Maurizio C. <seg...@ti...> - 2004-07-10 14:06:31

On Saturday 10 July 2004 15:18, Maurizio Colucci wrote:
> Hi Dario
>
> On Saturday 10 July 2004 06:23, Dario Pedicini wrote:
> > Uhm, I think they're ok in their place. We risk producing a confusing
> > interface, with just too many controls.
>
> But I am not proposing to add control, just to move them.
>

Anyway, as an experiment, the scrolling buttons have been moved to the right 
in CVS.

Let's see how it works.

mau

[Logicaldesktop-general] Re: About the scrolling buttons

From: Maurizio C. <seg...@ti...> - 2004-07-10 13:18:09

Hi Dario

On Saturday 10 July 2004 06:23, Dario Pedicini wrote:
> Uhm, I think they're ok in their place. We risk producing a confusing
> interface, with just too many controls. 

But I am not proposing to add control, just to move them.

> Where they are now, they'll be 
> used only from who see and know them, and they won't disturb the vision
> of the rest of the interface.

OTOH, on the right side the button would look more familiar. I am afraid LD 
look a bit too "different", it could slow down acceptance.

> I had another idea. Right click has no use actually. We could set it to
> completely reset the selections (eliminating also the "deselect all"
> button: in my opinion the interface is a bit heavy to be really usable).

We can add the right click feature, but it is not discoverable, so we cannot 
remove the deselect-all button.

> We could even consider associating some common keys to other functions
> (the interfaces which are considered the best in the world, like the
> Maya3D one, are all made on the concept that the user has a simpler life
> if he can interact with both the right hand -mouse- and left hand
> -keyboard common keys-). This would make LD _very_ popular!

Ok, but let's not forget that Maya takes much time to be learned, it is not 
discoverable.

Mau

Re: [Logicaldesktop-general] Optimizations

From: Maurizio C. <seg...@ti...> - 2004-07-10 12:15:27

On Friday 09 July 2004 06:43, Dario Pedicini wrote:
> Third, we could provide a function to be used with the mouse scroll
> button, to better browse the options lists.

Done in CVS! :-)

(wait for CVS to catch up)

[Logicaldesktop-general] About the scrolling buttons

From: Maurizio C. <seg...@ti...> - 2004-07-10 12:14:05

Maybe we should move them to the side of the panels?

[Logicaldesktop-general] Python compiler

From: Dario P. <d.p...@fa...> - 2004-07-09 13:53:41

It's called Psyco, it produces faster code. You got to recompile files
every time you change the source though: it's not human readable anymore
:)
http://psyco.sourceforge.net/
It's not at the level of C bytecode at all, but it's quite smart =)

About hiding directories in the way I suggested, we could provide an
indexing service, a kind of "locate" service in the user space, but it's
a lot of work to make it good, so we can surely wait, for that :)

Re: [Logicaldesktop-general] Optimizations

From: Maurizio C. <seg...@ti...> - 2004-07-09 13:43:01

On Friday 09 July 2004 06:43, Dario Pedicini wrote:
> Hi,
> I have a few suggestions (even if I've no idea of how make those changes
> =] ).
> First, separate definitions (verbs, programs), from the body of the
> program (interface, functions etc) putting them in libraries or so. This
> would make developing more linear.

Agree
> Second to consider, for the future, using a python compiler to produce
> faster code.

Do they exist? I didn't know! :-)

> Third, we could provide a function to be used with the mouse scroll
> button, to better browse the options lists.

Yes. Maybe smooth scrolling.

> We could also find the way to make LD hide also the directories if their
> content is useless to our purpose (or also if for example they contain
> only text files which aren't readable by the user).

I don't think that's possible. You'd have to process subdirs recursively, too 
slow.

> Another thing we could do is to make a double-click (and/or the Enter
> key) opening a directory or executing the action, as an alternative for
> having to click on the description on the top or on the small door icon:
> browsing via keyboard is a great feature in my opinion!

100 % agree

> For now that's it =) .
> I can't start coding right now because I've some exams in the next week

Me too! :-)

bye!

[Logicaldesktop-general] Optimizations

From: Dario P. <d.p...@fa...> - 2004-07-09 13:26:49

Hi, 
I have a few suggestions (even if I've no idea of how make those changes
=] ).
First, separate definitions (verbs, programs), from the body of the
program (interface, functions etc) putting them in libraries or so. This
would make developing more linear.
Second to consider, for the future, using a python compiler to produce
faster code.
Third, we could provide a function to be used with the mouse scroll
button, to better browse the options lists.
We could also find the way to make LD hide also the directories if their
content is useless to our purpose (or also if for example they contain
only text files which aren't readable by the user).
Another thing we could do is to make a double-click (and/or the Enter
key) opening a directory or executing the action, as an alternative for
having to click on the description on the top or on the small door icon:
browsing via keyboard is a great feature in my opinion!
For now that's it =) .
I can't start coding right now because I've some exams in the next week
but then I should find the time.
Ciao,
Dario.