Wine Start menu

[Robert van Herk]

Hi all,

As some of you might know I am working on a Wine Start menu, for Linux.

I have heard different things on this list about the way Windows treats 
the start menu.

Some told me that it would be better to make a Windows (wine) client 
that reads the actual start menu by querying a Wine dll, while others 
told me that this is not neccesairy as all the links are contained in 
the Start Menu directory.

From looking at my Windows installation, I must agree that it seems 
that all items in Programs are indeed in the Start Menu directory.

So, my question is: would it be enough to create just a Linux program 
that synchronizes with this directory? Can anyone give me an example of 
a lnk file that IS actually missing in a Start Menu directory, but is 
there in his Program folder in the Windows start menu?

Does anyone know how far people came at parsing the lnk files for Linux? 
I read something about the .lnk format, but I don't really feel like 
writing my own link file parser ;-). Does anybody know of parts of other 
software that could be recycled here?

Grtz,

Robert

[Gregory M. Turner]

On Monday 13 October 2003 01:46 pm, Robert van Herk wrote:
> So, my question is: would it be enough to create just a Linux program
> that synchronizes with this directory? Can anyone give me an example of
> a lnk file that IS actually missing in a Start Menu directory, but is
> there in his Program folder in the Windows start menu?

Not offhand, but my guess is that, eventually, some fancy feature will be 
lacking unless wine/winelib is brought into the picture, for example, 
control-panel, "My Computer" or context-sensitive right-click menu-actions, 
the fancy docking capability of Windows Media Player 9, etc.  One thing I do 
know for sure -- those don't /have/ to be .lnk files in there... they could 
be .exe's or .mp3's or whatever, and in Windows, "the right thing" would 
happen....

That is not to say that a rational cost/bene analysis will not ultimately 
favor a pure-linux implementation, depending on where your code is going.... 
but my bias would be towards a wine/winelib implementation.  Do you forsee 
this code going into wine or into kde/gnome, or remaining as a separate 
thing?  What relationship would you like between your code and wine's 
"explorer.exe," once it has one?

Codeweavers has done a lot of work with shortcuts & menuitems, to make them 
work with different distros... so they might know what some of the 
nitty-gritty details are (Unfortunately, I do not).  You may also want to 
look at LiteStep, ReactOS's explorer, and other windows shell-replacement 
software for clues.

Good luck!

[Robert van Herk]

> That is not to say that a rational cost/bene analysis will not ultimately 
> favor a pure-linux implementation, depending on where your code is going.... 
> but my bias would be towards a wine/winelib implementation.  Do you forsee 
> this code going into wine or into kde/gnome, or remaining as a separate 
> thing?  What relationship would you like between your code and wine's 
> "explorer.exe," once it has one?

Since I want the menu to really integrate into your Linux environment, 
this would be a Linux executable. I guess than that if I'd want to query 
Wine for the needed links, that would have to be in a Wine executable. 
The problem is that this seems a bit of an overkill:

- I'd have to write a communcation protocoll between the Wine app and 
Linux app
- A wine process would always be running, just for serving the menu. 
Killing your wineserver (what I personally like to do often :-)) would 
kill the start menu server too... It would take some fancy programming 
to get it back up again without the user noticing it (i.e. without some 
horrible crashing of the Linux client ;-))

Therefore, I would prefer to write just a number of Linux apps, one for 
each desktop environment. Maybe some could be merged together.

In the current setup, an abstract menu is kept as a datastructure in 
which the menu items are stored. So, for the different Linux desktop 
environments, only the very frontend of the application would have to be 
rewritten.

Thus, I am currently thinking whether it is worth it to make a Wine 
client / linux server setup. Is there a way to access the Wine dll's 
from a Linux program? This would ease things up severely.
> Codeweavers has done a lot of work with shortcuts & menuitems, to make them 
> work with different distros... so they might know what some of the 
> nitty-gritty details are (Unfortunately, I do not).

Do you know if it is possible to recycle code from them? Since there 
product seems to be commercial...?

Greetings,
Robert van Herk

[Jeremy White]

> > Codeweavers has done a lot of work with shortcuts & menuitems, to make 
> > them work with different distros... so they might know what some of 
> > the nitty-gritty details are (Unfortunately, I do not).
>
> Do you know if it is possible to recycle code from them? Since there 
> product seems to be commercial...?

I'd rather you didn't recycle our code; we do have some nice bits
that we've put an awful lot of blood, sweat and tears into, and
they tend to be the bits that encourage folks to send money our way...

With that said, we're cheerful to share knowledge and tips; we've
learned an awful lot the hard way.  That's why Mike is so eager to
see this done, btw...

Cheers,

Jer

[Mike McCormack]

Hi Robert,

It's probably easier to just go with the link file reader first, but it 
will have some limitations:

1) you won't be able to get stuff in the shell namespace (eg. desktop 
icons, Control panel stuff)

2) you'll have to hardcode the location of the start menu (you can 
change the location of the start menu by playing with registry keys... 
see SHGetSpecialFolderLocation).

3) you'll have to duplicate the code to read .lnk files (see 
dlls/shell32/shelllink.c), and the code to read the icons from .exe files

4) if you want to support adding other stuff (eg. a .txt file) to the 
menus, you'll have to read the registry to get the right association, to 
pull the right icon from an exe.

I guess that's not too much of a problem, and it's probably not worth 
the effort to make it perfect.

The code that wine Crossover uses to generate KDE/Gnome menus is already 
merged into Wine.  We just have a more extensive wineshelllink script 
that deals with more corner cases.

Mike

Robert van Herk wrote:
> Hi all,
>
> As some of you might know I am working on a Wine Start menu, for Linux.
>
> I have heard different things on this list about the way Windows treats 
> the start menu.
>
> Some told me that it would be better to make a Windows (wine) client 
> that reads the actual start menu by querying a Wine dll, while others 
> told me that this is not neccesairy as all the links are contained in 
> the Start Menu directory.
>
> From looking at my Windows installation, I must agree that it seems 
> that all items in Programs are indeed in the Start Menu directory.
>
> So, my question is: would it be enough to create just a Linux program 
> that synchronizes with this directory? Can anyone give me an example of 
> a lnk file that IS actually missing in a Start Menu directory, but is 
> there in his Program folder in the Windows start menu?
>
> Does anyone know how far people came at parsing the lnk files for Linux? 
> I read something about the .lnk format, but I don't really feel like 
> writing my own link file parser ;-). Does anybody know of parts of other 
> software that could be recycled here?
>
> Grtz,
>
> Robert